Config-as-code foundation: improvementSignal as a converged feature (global + per-repo)

[JSONbored]

Context

Part of #4737 (parent epic — foundation phase). Every other sub-issue in this
epic depends on this landing first: it establishes the config-as-code surface the deterministic tier,
LLM tier, and panel surfacing all read from.

The problem

There is no config surface yet for a feature that doesn't exist. But this repo has a hard-won,
now-unified pattern for exactly this kind of addition (src/review/feature-activation.ts,
resolveConvergedFeature / resolveFeatureActivation, shipped in #4616 specifically to stop each new
advisory feature from growing its own bespoke *-wire.ts precedence rule) — this issue is the first real
test of that pattern serving a genuinely new feature end to end.

Requirements

1. Add improvementSignal as a ConvergedFeatureKey (packages/gittensory-engine/src/focus-manifest.ts
CONVERGED_FEATURE_KEYS, alongside rag/reputation/unifiedComment/safety/grounding/e2eTests/screenshots).
   Standard mode (resolveFeatureActivation's "standard" mode) — no asymmetric force-on/force-off
   exception is needed here (unlike safety/grounding): this is a read-only advisory signal, not a
   security control, so a repo-level false should behave like every other plain override.
2. Global default: OFF. A deployment must opt in via the standard env kill-switch
   (GITTENSORY_REVIEW_IMPROVEMENT_SIGNAL or equivalent, matching the naming convention of its converged
   siblings) before any repo can enable it.
3. Per-repo override: .gittensory.yml review.improvement_signal: { enabled: true|false|null },
   layered the same way review.screenshots.enabled already is (see .gittensory.yml.example's existing
   screenshots block for the exact doc-comment convention to mirror — config-as-code enable/disable
   layered on top of, never replacing, the env-var gate).
4. DB + Drizzle: whatever column(s) RepositorySettings needs for the per-repo override
   (src/db/schema.ts, a new migration under migrations/) — follow the existing pattern used for the
   other converged-feature repo overrides, don't invent a new shape.
5. OpenAPI: run npm run ui:openapi for the new field(s); update RepositorySettingsSchema
   (src/openapi/schemas.ts) so the settings-parity check passes.
6. This issue does NOT need to build the signal itself — it wires activation only. The deterministic
   tier (sibling sub-issues), LLM tier (sibling sub-issue), and panel surfacing (sibling sub-issue) all
   read resolveConvergedFeature(env, manifest, "improvementSignal", repoFullName) and no-op entirely
   when it resolves false, so this PR should be shippable and testable in complete isolation (the
   resolver will simply always return false until a downstream sub-issue gives it something to gate).

Acceptance criteria

• improvementSignal is a full ConvergedFeatureKey resolved through the shared core, not a bespoke
  wire file.
• Global-off by default; env kill-switch + per-repo .gittensory.yml override + DB column all wired,
  with .gittensory.yml > DB > defaults precedence holding (test it explicitly).
• OpenAPI regenerated and committed; settings-parity check passes.
• .gittensory.yml.example documents the new block in the same voice/format as its siblings.
• Tests cover the full resolution matrix (env off, env on + no override, env on + repo true, env on
  + repo false), matching the sibling-feature test pattern already established for Unify per-feature *-wire.ts activation behind one shared resolver #4616's migrated
  features.

[linear-code]

JSO-3421