feat(decisioning): forward ctx.agent to tasks_get accounts.resolve

[bokelley]

Summary

• `tasks_get` now resolves the calling `BuyerAgent` (when an `agentRegistry` is configured) and threads it to `platform.accounts.resolve` as `ctx.agent`.
• Closes the asymmetry left by PR feat(decisioning): forward ctx to AccountStore.upsert/list (#1310) #1315 + feat(decisioning): forward ctx.agent to all AccountStore methods #1321 — the custom-tool path historically bypassed registry resolution because it sits outside the dispatcher's main handler-dispatch flow.
• Status enforcement is deliberately NOT replicated. A buyer suspended after kicking off an HITL task must still be able to poll for terminal state. Tests pin both contracts so a future refactor can't silently tighten status enforcement onto the polling path.

Why this needs fixing

The contract docstrings landed on `upsert?` / `reportUsage?` / `getAccountFinancials?` in the prior two PRs say "prefer `ctx.agent` for principal-keyed gates." That guidance was a half-truth as long as `tasks_get` skipped registry resolution: an adopter who wrote their resolver to key on `ctx.agent` would see it undefined on every `tasks_get` call and have to special-case the polling path.

Why status enforcement stays off the polling path

The dispatcher comment at `create-adcp-server.ts:2796-2802` makes the policy explicit: status checks (suspended/blocked → 403) deliberately skip on `tasks_get` polls and background webhooks because refusing the poll would strand in-flight work with no visibility. This PR pins that policy in tests rather than relying on its current emergent behavior, so future tightening fails loudly.

What's NOT in scope

• Replicating the dispatcher's full agent-resolution-and-status-enforcement seam in the custom-tool path. The right long-term shape is v6.1's native MCP `tasks/get` method dispatch, which puts the polling path on the regular handler-dispatch path naturally. This PR is the bounded contract patch that holds until then.

Compatibility

No behavior change for adopters that don't read `ctx.agent` from inside their resolver.

Test plan

• 6 new tests in `test/server-tasks-get-agent-forwarding.test.js`:
  • resolved BuyerAgent reaches `accounts.resolve` from `tasks_get`
  • no agentRegistry configured → `ctx.agent` undefined (no regression)
  • agent is shallow-frozen before threading (mirrors dispatcher freeze contract)
  • registry throwing on the poll falls through to `agent: undefined` (poll still succeeds)
  • suspended agent can still poll `tasks_get` (policy)
  • blocked agent can still poll `tasks_get` (policy)
• All 154 tests across adjacent files (`server-account-store-ctx-forwarding`, `server-buyer-agent-resolve-seam`, `server-buyer-agent-credential-synthesis`, `server-decisioning-from-platform`, `server-ctx-metadata-leak-paranoia`) pass.
• `npm run build` clean; `npm run format` clean; `npm run typecheck:skill-examples` clean.

🤖 Generated with Claude Code