Follow-up from #666

PR #666 ("feat(composer): add configurable run defaults") added the configurable run-default surfaces for the New Task composer — centralized run-mode precedence, quick-task as the cold source, and truthful forced/eligible Worktree controls. It was reviewed, approved, and manually UI-QA'd (PASS), and it ships route-level plus unit coverage. It does not, however, close three specific test-coverage gaps for these run defaults. This issue consolidates them so the behaviour is locked in by automated tests; it is non-blocking follow-up work, not a fix of the PR.

Reviewer's request

From @pat-lewczuk on the QA run comment (#issuecomment-5078905212), and echoed by @pkarw in #issuecomment-5077590302:

🧪 Follow-up: add a UI/integration test

This change ships no browser-level test for the composer run-default surfaces (the PR adds unit/component .test.tsx coverage but nothing under web/app/e2e). The UI QA above was manual; lock it in with an automated test (run /om-integration-tests).

Scenario (derived from the manual run above):

1. Setup: ensure a git-backed project is loaded; via the workspace config API set composerDefaults to { autonomous: null, worktree: null } (inherit); ensure a skill flagged interactive: true exists in a skills scan dir (fixture).
2. Act & assert — New Task composer (/new):
   • Cold load → source pill = quick-task, Worktree checked, Autonomous unchecked.
   • Select the interactive skill → [data-slot="interactive-skill-hint"] visible, [data-slot="worktree-toggle"] and the Autonomous toggle both aria-checked=false, neither disabled; toggling either flips it (overridable).
3. Act & assert — Settings › Resources (/settings/global/resources):
   • [data-slot="resources-composer-defaults"] shows the "Autonomous by default" and "Use a worktree by default" selects; set Autonomous → On; reload; assert the select persists "On" and GET /api/workspace/config returns composerDefaults.autonomous=true.
4. Teardown: reset composerDefaults to inherit and remove the interactive-skill fixture.

Acceptance criteria

The three gaps below share the theme "test coverage for the composer configurable run defaults" and should all be closed:

• Unit — web/app/src/routes/new-task-draft.ts: resolveComposerRunMode's forceWorktree === true branch has no direct unit assertion. Add a case to web/app/src/routes/new-task-draft.test.ts asserting that a forced worktree (e.g. a multi-step workflow source) forces worktree: true regardless of explicitWorktree / interactive.
• Component/UI — web/app/src/routes/new-task.test.tsx: add a component test asserting the forced/disabled Worktree toggle (worktreeForced → disabled + disabledReason) for a multi-step workflow.
• Browser/integration — add a browser-level test (under web/app/e2e, via /om-integration-tests) for the composer configurable run-defaults flow, covering the scenario quoted above: the cold quick-task default, the interactive-skill both-toggles-off (overridable) recommendation, and the workspace New-task-defaults persistence through GET /api/workspace/config.

Related: #666, #660, #657