fix(hub): resolve the engine from backend_json for runtime mode/model switching

[physercoe]

The bug

Changing a steward's model or permission mode never worked. Both halves of
the set_model / set_mode path resolved the engine family from agents.kind
— which for a steward is the persona template (steward.claude-m4), not the
family (claude-code):

site	what happened
resolveRuntimeModeSwitch	matched no family → unsupported → 422 "engine does not support runtime mode switching"
respawnWithSpecMutation	keyed flagForField the same way → errUnknownFamilyField, had a request ever reached it

So the feature was dead end to end for the agent class this product is built
around, while working fine for a direct engine spawn.

Why no test caught it. seedAgentWithSession wrote no backend_json, so no
test in the file could express a steward at all — every case seeded
Kind: "claude-code", which passes whether the code reads kind or
backend_json. The seed now takes a Backend, and the new cases use the
separating input: Kind is a template id and only Backend names the engine.

Third instance of this class, after the /compact marker (R3) and the
desktop's engine-gated affordances (R2) — same column, same mistake. The
canonical fix, with its rationale, was already written at
handlers_sessions.go:1088.

The trap inside the fix

spliceResume is also family-keyed, and was unreachable for stewards only
because the flag table rejected them first. The repo had already predicted this
exact failure — resume_splice_table_test.go:55:

"Latent (flagForField gates first), but it would have become a silent
cold-start the moment antigravity gained a mode/model flag."

Resolving the engine at one site and not the other would have replaced a loud
422 with a silent loss of the resume cursor — every steward's model flip
cold-starting mid-session with the transcript visibly jumping. Both lookups
moved together, and TestRespawnWithSpecMutation_StewardKeepsResumeCursor pins
it.

Kind: on the respawn itself deliberately stays agents.kind — it re-spawns
the same persona, not a bare engine.

Verification

• 4 new tests: steward resolves its engine, steward keeps its resume cursor,
  legacy {} rows still fall back to kind, and a table over the routing gate
  (steward/claude, steward/codex, direct spawn, unknown engine).
• 5 mutations, all killed — one per site, one per legacy fallback, and the
  resume-splice trap.
• Full go test ./... green (0 failures); gofmt clean on changed files; CI
  doc lint set passes.

Why now

Found while surveying the consumer side of R6 (composer pills) in the
vision-parity plan. Building the pill first would have shipped a control that is
disabled for exactly the agents it exists for — and read as an engine
limitation rather than our bug. The plan's R6 entry records this along with
three of its own specifics that needed correcting.