Factory sessions run on the T3 project's default model, not their own config keys #93

Outcome

The factory starts each issue's session on the T3 project's default model, the same model a person gets in a new thread on that project, instead of its own model_instance and model in the machine config. The Model instance and Model rows leave the factory settings page (/settings/factory), so a person picks the model once, in T3.

Acceptance criteria

• A launch and a relaunch (runner/start.ts, runner/relaunch.ts) use the T3 project's defaultModelSelection, read from the project row that FactorySessions.findProject already loads by workspace root (ProjectStoreV2.findActiveByWorkspaceRoot). When that is null they use the server settings' defaultModelSelection. Unit tests cover all three cases: project default, settings fallback, and neither.
• When neither is set, nothing launches and the issue is not claimed. The launch returns ok: false with a detail that names the fix, e.g. no default model: set one on the T3 project or in Settings, handled the same way as the existing no T3 project for this repo on this machine. A unit test asserts the detail.
• The run record still writes model_instance and model (start.ts, relaunch.ts), now filled from the resolved selection, so /factory and the ledger show which model each run used.
• parseMachineConfig no longer reads model_instance or model. A file that still has them loads without error, and each one is reported once as a warning that it is no longer used (not as an unknown-key error), so the running factory keeps loading its current ~/.config/t3fac/factory/config.yml after the upgrade. A unit test loads a file with both keys and asserts it loads with the warnings.
• Saving from the settings page (saveMachineConfig / editMachineConfig) deletes model_instance and model from the file when they are present, and keeps every other key and comment as written. A unit test asserts it.
• MachineConfigFields, MachineConfigDraft, the report, the web api.ts types and FactorySettingsPanel drop both fields; the page has no Model instance or Model row. DEFAULT_MODEL_INSTANCE is removed.
• factory/config.example.yml and factory/README.md drop the two keys and say the model comes from the T3 project's default model, falling back to the T3 settings default.
• vp test run on the touched test files passes, and vp run --filter t3 typecheck passes.

Depends on

• Factory pages on a phone and over the tailnet #61

Notes

Why: T3 already stores a default model per project and in settings (packages/contracts/src/project.ts defaultModelSelection, packages/contracts/src/settings.ts defaultModelSelection). A second selector in the factory config duplicated it, and nothing checked that model_instance named a configured provider.

Waits on #61 because both edit apps/web/src/factory/settings/FactorySettingsPanel.tsx.

Settled choices:

• Precedence is project default, then settings default, then refuse. There is no hard-coded fallback model.
• The retired keys are tolerated with a warning rather than rejected, so the upgrade does not stop the factory that builds it.

Reference

• Upstream's AGENTS.md applies. Run only the tests and typechecks for the paths you touch, never the repo-wide checks.
• Edit no upstream file that is not listed in factory/SEAMS. A new seam needs a line in factory/SEAMS and a reason in the PR body.