fix(config): wire badgeEnabled into the .gittensory.yml manifest parser

[JSONbored]

Parent: #1936

Problem

.gittensory.yml.example documents badgeEnabled under settings: as a config-as-code-settable field, and it's fully wired everywhere else (DB column, RepositorySettings type, API, the badge consumer itself) — but FocusManifestSettings's Pick<RepositorySettings, ...> list and parseSettingsOverride in src/signals/focus-manifest.ts both omit it. So a maintainer following the documented example and setting badgeEnabled in .gittensory.yml has the value silently ignored — the manifest parser never reads it, and the DB/dashboard value is the only thing that actually takes effect. This is the exact class of bug the gate itself caught on #2467 (an undocumented/mismatched config-as-code field).

Requirements

• Add badgeEnabled to FocusManifestSettings's Pick<RepositorySettings, ...> list in src/signals/focus-manifest.ts.
• Add the corresponding r.badgeEnabled read + normalization in parseSettingsOverride, mirroring the existing autoLabelEnabled boolean-field pattern exactly.
• Verify resolveEffectiveSettings correctly overlays the manifest value over the DB value once wired (no separate change expected here, but confirm via test).

Deliverables

• badgeEnabled added to the manifest Pick-list and parser.
• A regression test proving .gittensory.yml's badgeEnabled value actually overrides the DB-stored value (currently would fail, since the field is silently dropped).

Acceptance criteria

• Setting badgeEnabled: true/false in .gittensory.yml actually changes the resolved effective setting, overlaying the DB value as documented.
• No regression to any other manifest field's parsing.

Expected outcome

.gittensory.yml.example's documentation and actual parser behavior match for badgeEnabled — closing a silent config-as-code parity gap where a documented, seemingly-working setting was actually a no-op.

[linear-code]

JSO-2496