Adapter: find a project, launch a thread and read its status in-process #5

Outcome

Factory code can start an agent session in its own worktree and read where it stands through softfac-shaped types, calling T3's services directly instead of the wire protocol.

Acceptance criteria

• apps/server/src/factory/t3/sessions.ts provides an Effect service FactorySessions with findProject(workspaceRoot), launch(request), status(threadId) and thread(threadId). Each has the meaning of the call with the same name on softfac's Sessions trait in src/t3.rs: the same inputs, and the run statuses preparing|queued|starting|running|waiting|completed|interrupted|failed|cancelled|rolled_back.
• status reports the latest run (highest ordinal, leaving out a cancelled run that never started), that run's last assistant message, and the thread's branch, worktreePath and archived. thread reports the thread fields alone and works when the run cannot be read.
• launch starts a thread in a new worktree from baseRef, or from the branch tip on origin when startFromOrigin is set, in full-access runtime mode and the default interaction mode, with the given model instance, model, title and first message, under the caller's commandId. A second launch with the same commandId returns the same thread and starts nothing.
• apps/server/src/factory/t3/paths.ts gives the base dir, the worktrees dir and the factory data dir <base>/factory, from ServerConfig.
• apps/server/src/factory/t3/sessions.contract.test.ts runs the real orchestration layers with the test provider from packages/provider-testing. It launches a thread, waits for the run to complete, reads the last assistant message, checks the worktree exists on the branch status reports, and shows that a repeated commandId starts one thread.
• The boundary test still passes: only files under apps/server/src/factory/t3/ import T3 internals.

Depends on

• Factory skeleton: an empty FactoryLayer wired in through one seam #1

Notes

In-process entry points: ThreadLaunchService (orchestration-v2/ThreadLaunchService.ts), OrchestratorV2.dispatch, ProjectionStoreV2, EventSinkV2. See how ws.ts handles orchestration.launchThread and how orchestration-v2/http.ts answers GET /api/orchestration/threads/:id, and call the same services. PullRequestSyncReactor.ts is an in-process example. softfac's tests/fixtures/t3_thread_snapshot.json shows the fields it reads.

Reference

• softfac, the Rust factory this ports, pinned at rawphp/softfac@bf273a1. Read it from a separate clone: git clone --filter=blob:none https://github.com/rawphp/softfac /tmp/softfac-ref && git -C /tmp/softfac-ref checkout bf273a1d93651992b4fc95b4dd6c111f8f3322cf. Its docs/lifecycle.md, docs/reference/ledger.md and docs/issues.md describe the behaviour; its tests pin it.
• Design: factory/docs/design.md in this repo.
• Upstream's AGENTS.md applies. Run only the tests and typechecks for the paths you touch (vp test run <path>, vp run --filter t3 typecheck), 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.
• Port behaviour, not code: port the named test cases first (TypeScript, vitest / @effect/vitest), then make them pass. Exact comment and ledger wording is ported as is.