fix(config): settings.commandAuthorization is documented as config-as-code but silently ignored by the parser

[JSONbored]

Parent: #1936

Problem

.gittensory.yml.example documents settings.commandAuthorization as settable config-as-code ("Command authorization role policy... omit to inherit the safe built-in default"). However FocusManifestSettings does not include commandAuthorization in its field list, and parseSettingsOverride never reads it from the parsed YAML/JSON at all — it's dropped without even a warning. The field is only actually settable via the dashboard/API route, which persists to the DB. This fails toward the safe side (the DB/default policy silently continues to apply, so no privilege is granted by the omission) — but it's a real config-as-code parity gap, and this project's stated convention is that .gittensory.yml should be authoritative (yml > DB > defaults).

Failure scenario: a maintainer, believing config-as-code is authoritative per this repo's own convention, adds settings.commandAuthorization: { commands: { gate-override: [maintainer] } } to .gittensory.yml to tighten who can invoke /gate-override, assuming this restricts the command the same way every other settings.* field does. The write is silently dropped; the DB-stored (possibly more permissive) policy stays in effect with no warning surfaced anywhere. The maintainer has a false sense that the restriction is live.

Requirements

• settings.commandAuthorization must actually be honored when set via .gittensory.yml, matching every other documented config-as-code field's behavior.

Deliverables

• Add commandAuthorization to the Pick<RepositorySettings, ...> union in FocusManifestSettings.
• Parse/normalize it in parseSettingsOverride using the existing normalizeCommandAuthorizationPolicy/related validators (src/settings/command-authorization.ts), folding any validation warnings into the manifest's warnings output.
• Confirm resolveEffectiveSettings's spread correctly overlays the parsed value over the DB-stored value, matching the yml > DB > defaults convention used elsewhere.
• Add a regression test: set settings.commandAuthorization via .gittensory.yml, assert it overrides the DB-stored policy.

Acceptance criteria

• A .gittensory.yml-configured commandAuthorization policy is actually enforced, not silently dropped.
• An invalid commandAuthorization value in .gittensory.yml produces a visible warning rather than silent omission.

Expected outcome

Config-as-code becomes authoritative for command authorization the same way it already is for every other settings field, closing a real parity gap in a security-relevant control.

[linear-code]

JSO-2369