feat(review): auto-trigger E2E test generation on the manifest_missing_tests signal

[JSONbored]

Part of #4189. Depends on #4194.

Context

gittensory already has a deterministic "this PR probably needed tests" detector — it just doesn't act on it beyond a warning-severity advisory finding today:

// src/signals/focus-manifest.ts:674
if (manifest.testExpectations.length > 0 && testFileCount === 0 && passedValidationCount === 0) {
  // ... pushes a "manifest_missing_tests" finding (focus-manifest.ts:678)
}

It only fires when (a) the repo has opted into .gittensory.yml's testExpectations list, and (b) the PR touched zero test-path files, and (c) the PR body carries no validation note. The inputs are computed at the call site: testFileCount = changed files matching isTestPath (src/queue/processors.ts:9011), passedValidationCount = hasValidationNote(pr.body ?? "") ? 1 : 0 (processors.ts:9013). The resulting finding (code: "manifest_missing_tests", src/queue/processors.ts:955 / focus-manifest.ts:792) is currently just advisory text in the review comment — nothing downstream consumes it as a trigger.

Not every PR should get an E2E-test-generation pass (cost, noise), and pure explicit-ask (#4195) undersells the automation gittensory already has. This issue promotes the existing boolean into an actual trigger.

Requirements

• When manifest_missing_tests fires for a PR and features.e2eTests is enabled for the repo (feat(review): resolver gate for e2eTests — src/review/e2e-test-gen.ts #4192's gate), automatically invoke the same generation-and-render path feat(review): dispatch wiring for e2eTests in queue/processors.ts #4194 wires up for the explicit command — do not invent a second heuristic; key off the identical testExpectations.length > 0 && testFileCount === 0 && passedValidationCount === 0 boolean (or filter guidance.findings for code === "manifest_missing_tests") rather than re-deriving "PR probably needs tests" from scratch.
• This auto-trigger must be resolved unconditionally alongside the other deterministic manifest overrides in processors.ts, the same place feat(review): dispatch wiring for e2eTests in queue/processors.ts #4194 resolves e2eTestGenEnabledForReview — wire it as an additional condition on the existing flag, not a parallel code path.
• Still comment-delivered, still advisory, still no execution — this issue is purely about when generation fires automatically, not a change to delivery mode (that's feat(review): delivery escalation for generated E2E tests — commit / follow-up-PR modes #4197) or execution (feat(selfhost): execute generated E2E tests against the PR preview URL #4198).
• The explicit @gittensory generate-tests command (feat(commands): wire @gittensory generate-tests PR-comment command #4195) remains available regardless of whether this signal fired, matching CodeRabbit's own explicit-ask model — auto-trigger and explicit-ask are additive, not exclusive.
• Guard against double-generation: if the signal already triggered generation for the current commit SHA, a subsequent explicit command on the same SHA should reuse or clearly regenerate (maintainer's call — flag it as an open question in the PR if ambiguous during implementation) rather than silently double-billing an LLM call.

Deliverables

• Auto-trigger wired off the exact existing manifest_missing_tests boolean, no new heuristic.
• Tests: signal fires + feature enabled ⇒ generation triggers automatically; signal fires + feature disabled ⇒ nothing happens; signal doesn't fire + feature enabled ⇒ nothing happens (generation stays explicit-ask only); explicit command still works regardless of signal state.
• A decision (documented in the PR, not necessarily a new mechanism) on the double-generation edge case above.

Expected outcome

A PR that's genuinely missing test coverage (per gittensory's own existing detector) gets an E2E test suggestion automatically, with zero contributor/maintainer action required — while a PR that already has adequate test evidence never triggers an unnecessary LLM call.

Resources / examples

• src/signals/focus-manifest.ts:577-712 (buildFocusManifestGuidance, the trigger condition at line 674)
• src/queue/processors.ts:9011-9024, 955 (the call-site inputs and the finding's public-safe policy entry)

Effort

S — the hard part (the detector) already exists; this is a trigger-wiring issue.

[linear-code]

JSO-3228