The host mints Work Contexts a core verifier cannot read, so a module read through an MCP capability fails #1082

What fails

A Work Context minted by accounts' StartTask is signed in sdk-go/workcontext's format (a JSON payload). A runtime that verifies with core/workcontext refuses it before any request leaves it:

work context: not a core token: the payload is a JSON object;
this capability is a deterministic protobuf encoding

So the MCP module-read flow — tool call → StartTask mint with the viewer's bearer → /v1/<alias>/* with the minted capability — dies at the third step. Measured end to end through this host's real Gateway.ServeHTTP during the review of #1019 (rounds 3 and 4); main fails identically, so this is not introduced by #1019.

Why it is not a one-line switch

• The two formats differ at the encoding, not at a field: both sign basev0.WorkContextV1, sdk-go as JSON, core as deterministic protobuf. core refuses an sdk-go token even in Inspect, which verifies no signature.
• So mint and verify must move together: there is no partial switch and no dual-read window (every token minted before the cutover is refused after it). TestTheWorkContextCutoverIsAtomic (accounts/pkg/adapters/work_context_cutover_test.go) pins this.
• The mint's entry condition is the blocked field: core requires WorkContextV1.seal with WorkSealV1.image_digest matching ^sha256:[a-f0-9]{64}$, and sdk-go emits no seal. At verify time the approved-build record is a sound source; at mint time it is not — the mint has to answer the digest of the build actually asking.

Done when

• The mint answers the seal from the requesting workload's build, and accounts mints and verifies with core/workcontext in one change.
• A test drives the three-request MCP flow through the real gateway and a core verifier and reads the module.
• TestTheWorkContextCutoverIsAtomic is deleted, not updated.

Related: #1019 (the confined capability this flow carries), #1030 (the presence-schema cold cutover, a separate change).