[tangzhiqiang]

What changed

Exposes the A2A Java SDK's operation-level authorization SPI in the Spring Boot starter. When a
TaskAuthorizationProvider bean is present, the autoconfigured requestHandler is wrapped with the
SDK's AuthorizationRequestHandlerDecorator, so host-side validation runs before the agent
executor is invoked:

Guard	Covers
checkCreate	message:send, message:stream (new task creation)
checkRead / checkWrite	task query/list, cancel, subscribe
recordOwnership / isTaskRecorded	task ownership tracking

• Rejections surface as a standard A2A error envelope: checkCreate returning false maps to a
  task-not-found error, while throwing a more specific A2AError subclass carries a custom reason.
• The decorator carries CDI Instance fields like the delegate, so it also stays behind the
  SpringCompatibleRequestHandler facade.
• The provider is resolved through ObjectProvider, so without such a bean the server is
  unchanged — no decorator is wired at all.

Why

Hosts receiving A2A traffic (e.g. a workbench behind an MSB gateway) need a business-owned
validation point before the agent executor runs. The secondary-authentication specification requires
every provider-side call to be validated against signature headers
(app-id / timestamp / sign-alg / sign / signature) before business execution. A2AController
already places all request headers into the ServerCallContext state, so a provider implementation
reads them directly from the context and applies its validation steps.

Breaking changes

None. The new constructor parameter is an ObjectProvider, and the requestHandler bean stays
@ConditionalOnMissingBean, so an explicitly declared handler still wins.

Test results

mvn -B clean verify -pl workflow-engine,spring-boot-starter -am

• spring-boot-starter — A2AAutoConfigurationTest: 23 tests, 0 failures, 0 errors
  • new taskAuthorizationProviderRejectionRunsBeforeTheAgentExecutor — asserts the executor is
    never reached (executorRuns == 0) and a TaskNotFoundError is thrown
  • new requestHandlerIsCreatedWithoutAnAuthorizationProvider — asserts the handler still assembles
    with no provider present
• workflow-engine — module build green

mvn -B -pl samples -am verify

Local note (not a regression): on the contributor's Windows machine the samples reactor fails with
PortInUseException: Port 62478 is already in use (2 failures / 4 errors in SpringSpnDemoE2ETest).
The identical failure — same port, same counts — reproduces on the pristine 6b1c2ec baseline
without this commit, so it is a local port-binding issue, not something this change introduces.
CI (ubuntu-latest) is the authoritative gate for the samples module.

Docs

docs/en/API_REFERENCE.md and docs/zh/API_REFERENCE.md are updated in the same commit (zh/en kept
in sync), documenting the requestHandler behaviour plus a usage example.

Related issues

No tracking issue exists for this change (searched the issue tracker for TaskAuthorizationProvider
and authorization).