feat(keychain): materialize credentials for human sandbox sessions

[yzxcj797]

Implements the suggested direction of #550 — the session-materialization half. The in-sandbox link plumbing (ephemeralCredLinkScript, EPHEMERAL_CRED_DIR) is reused exactly as the issue prescribes; what was missing was a non-agent driver, which this adds.

What was unreachable

Every materialization path sat behind an agent capability token (handleKeychain's gate) and ran inside a turn. The Keychain interface already declared materialize/materializeOwn/materializeStanding; every sandbox driver already ran ephemeralCredLinkScript; renderUseScript already produced the shell-sourceable form. A human reaching the same sandbox interactively (SSH, browser IDE) had exactly the two bad options the issue names: a shared credential in the scope's home volume, or nothing.

The driver

Keychain.materializeStandingForUser(ownerId, scopeId) — materializeStanding's selection filtered to one person's credentials. The grants table is keyed by audience scope, so the filter is what makes a shared sandbox's sessions per-user: Alice's session materializes Alice's grants, never Bob's, even though both granted toward the same scope. Once-mode and expired grants are excluded identically to the agent path.

POST /v1/keychain/sessions { userId, scopeId, ttlMinutes? } — source-auth (auth: "source"): the caller is the trusted integration holding CORE_SIGNING_SECRET (the SSH/IDE attach helper), naming the human on the session — the same trust boundary the issue's "authenticated internal route" describes. It materializes the user's set, records a credential_usage row per credential exactly as a turn does, audits keychain.session.open, and returns the same renderUseScript output /keychain/use emits — the helper sources it in the user's shell, so the materialization lifetime and isolation semantics are identical to an agent turn's. TTL bounded: default 8h, max 12h.

DELETE /v1/keychain/sessions/:id — idempotent release: released usage rows + audit. GET /v1/keychain/sessions lists live sessions for operators. An expired session sweeps to released on next touch — no re-materialization past its TTL.

Destination.humanSession { userId, sessionId } — the non-agent counterpart of the web destination, so asks and audit can name where a materialization went (the issue's item 1).

What deliberately didn't change

The agent surface: existing routes, their capability gate, and turn-time materialization are untouched — the new routes are additive and source-auth-gated, so an agent token alone cannot reach them (and a source-auth caller was already trusted with the whole keychain surface these routes read).

Tests

• materializeStandingForUser returns only that person's standing grants — Alice + Bob both grant toward one scope; each session gets exactly one credential (their own), a third user gets nothing. Fails on main (no such method).
• materializeStandingForUser excludes once-mode and expired grants — pins the mode boundary.

Full keychain.test.ts: 43 passed / 1 pre-existing environment failure (sprites exec ... bad envelope — identical on clean main); keychain-ask suite green; tsc --noEmit clean.

Not included (per the issue's own scoping)

File-credential materialization for sessions (the agent path materializes files only via explicit /keychain/use re-fetch, and the same one-shot semantics deserve their own design), and the dashboard surface — the API + script contract here is the integration seam both would build on.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}