rootProviderModel reports provider-model-missing on every runDir run: the settle path short-circuits whenever ctx.resume is true, and createFileRunContext sets resume unconditionally

[drewstone]

Found while fixing #1233. Two separate defects, both verified by reading; neither is on the root stream, so neither is fixed there.

(a) Every runDir run reports provider-model-missing

supervise.ts (settle closure, ~3319-3321) short-circuits to rootProviderModelEvidence([]) whenever ctx.resume === true. createFileRunContext (run-context.ts:114) sets resume: true unconditionally. So every run with a run directory — all Discovery Lab runs — settles with:

rootProviderModel: { attempts: [], models: [], reason: 'provider-model-missing', status: 'unknown' }

regardless of what the executor observed. Measured on two winner runs whose roots demonstrably ran 222 and 304 tool calls (capability-per-parameter-cpp-{ds,glm}-20260915a). The per-attempt evidence already exists: the journal's metered records (scope.ts:1770, :2468) and runtimeOwnedDriveHarnessProviderEvidence(rootDriveHarness). Introduced in 5bcc1a7 (#814).

Fix: gate the short-circuit on an actual resume (a prior settle record or journal continuation), not on the context flag that every file-backed run carries.

(b) A bridge root serving an undated model id never records its served identity

bridge-executor.ts:711-722 records chunk.model only when observedModelHasSnapshot() (model-identity.ts:84: dated or @snapshot ids) and the wire model equals the requested id. A bridge root serving glm-5.3 or deepseek/deepseek-v4.1-flash — undated ids — therefore stays unknown even after (a) is fixed. The identity is on every chunk; it is discarded by the snapshot rule.

Fix: record the served id with a snapshot: false marker rather than discarding it; consumers that need a pinned snapshot can still refuse it.

Both are small; (a) is one condition. Filed separately from #1233 so the stream fix ships without them.

🤖 Generated with Claude Code