Decide whether a workload's sandbox pool selector should bound its `kind:'prompt'` leaves

Context

resolveRunWorkload() (packages/knative-server/src/server.ts:300-324) resolves a
sandboxPoolSelector from a WorkloadRecord.sandboxSelector (context-service.ts:13-26) and
returns it on the envelope:

return { ...body, sandboxPoolSelector: record.sandboxSelector };

For kind: 'prompt' leaves it deliberately does not, and only warns (:308-320, an ADR-0028
amendment dated 2026-09-01):

A prompt leaf DOES lease a pool sandbox now, and honors an envelope sandboxPoolSelector
(ADR 0028 amendment, 2026-09-01) — but a workload-addressed one still ignores the workload's own
selector. The workloadId gates existence (404 above) and nothing more.
Whether a workload's pool should bound its prompt leaves is a separate decision from making the
lease work at all; until it is taken, warn rather than change behavior here.

So the decision was explicitly deferred, with a warn as the placeholder. This issue is to take it.

Why it matters now

POST /runs strips any client-supplied sandboxPoolSelector at server.ts:553 by design ("never
accept a Kubernetes selector directly from an external run request"), so resolveRunWorkload() is
the only injection point for pool scoping on that path.

The Z8 multi-user control plane design
(docs/specs/2026-09-08-multi-user-control-plane-design.md
§2.6, §8.2, §11.1) needs a per-tenant selector so that two users' leaves cannot be placed on the same
pooled sandbox pod. The path a logged-in user's session turn takes is exactly kind: 'prompt' — the
one case the resolver declines. Until this is decided, the tenant-labelled pool partition cannot be
enforced, and multi-user isolation holds at the API, session store, and inference credential but
not at the sandbox.

Note this is not only a multi-user question: it affects the plain /runs + workloadId path too,
which is why Z8 recorded it as owed rather than deciding it unilaterally.

Options

1. Honour the workload's selector for prompt leaves — deletes the special case, one consistent
   rule for every kind. Changes existing behaviour for anyone dispatching a workload-addressed
   prompt leaf today, which is presumably why it was deferred.
2. Keep ignoring it; add a separate tenant-scoped selector channel — leaves /runs semantics
   untouched and gives the control plane its own path. Two mechanisms doing one job, and the warn
   stays forever.
3. Make it opt-in per workload record — a field on WorkloadRecord (e.g. boundPromptLeaves).
   Backward compatible, at the cost of another knob and another combination to test.

No recommendation offered here — the deferral predates the Z8 design and the tradeoff is mostly
about existing /runs consumers.

Acceptance criteria

• Decision recorded (ADR amendment to 0028, or a new ADR).
• The console.warn at server.ts:315-318 is removed or replaced by the chosen behaviour.
• A test pins whichever behaviour is chosen for kind: 'prompt' + workloadId.
• Z8 §8.2 / §11.1 updated to reference the outcome.

Raised out of the Z8 multi-user control-plane design (docs/specs/2026-09-08-multi-user-control-plane-design.md, §2.6 / §8.2 / §11.1), which records this as owed rather than deciding it.

Start with resolveRunWorkload() in packages/knative-server/src/server.ts, WorkloadRecord in context-service.ts, and the cited Z8 design sections. Review ADR-0028 and the three selector options with maintainers, then record the decision, update the resolver and its warning as needed, add coverage for a prompt leaf with workloadId, and update Z8 §8.2 and §11.1.