Standardize feature modules behind a common trait system

[MasonRhodesDev]

We keep landing in the same shape: a feature area (harnesses, directories, git actions, MCP, shortcuts, toasts, ...) needs to declare metadata, capabilities, overrides, and UI hooks, and every new call site has to match-arm against an enum instead of asking the feature itself.

Existing issues circling this:

• Unify agent harnesses behind a common capability interface #29 — harness capability trait (identity, launch, session, supports(...), keyboard).
• Feature-flag / capability registry with scoped sources (directory, harness, etc.) #37 — feature-flag / capability registry with scoped sources.
• Non-git folders spam PR warning toasts; directories need a capability interface #38 — directory capability interface.
• Project-scoped overrides for the git actions settings (commit preferences, etc.) #45 — project-scoped overrides for a feature's settings.
• Show keybinding in tooltips for controls that have one #64 — GUI element trait that ties controls to a ShortcutAction.

Proposal: design and land a single feature-module convention that all of the above slot into, instead of each one inventing its own trait. A feature module declares:

• Identity: stable id, label, icon.
• Scopes: where it can be configured (global / repo / project / task / session).
• Settings: typed setting leaves with defaults, overrides, and resolution order.
• Capabilities: boolean/enum supports(Feature) bits so UI can gate.
• Actions: named actions the feature exposes (maps to shortcuts, menu items, MCP tools, etc. — one declaration, many surfaces).
• Lifecycle hooks: init/teardown, reacting to scope changes (e.g. .git appears, harness updated, MCP toggled).
• Parsing/detection hooks: narrow, feature-owned escape hatches (e.g. status probes in Surface task status CTAs in the task list (working / awaiting input / idle / read / unread) #27), never free-floating per-tool code.

Payoff:

• Shortcuts page (Show keybinding in tooltips for controls that have one #64), MCP catalog (Central MCP server registry with per-harness toggles (persistent even when unused) #33), harness switcher (Unify agent harnesses behind a common capability interface #29), directory capability detectors (Non-git folders spam PR warning toasts; directories need a capability interface #38), and the feature-flag registry (Feature-flag / capability registry with scoped sources (directory, harness, etc.) #37) all read from the same registry instead of hand-rolled enums.
• Adding a feature = implementing the trait + registering; no N-way edits.
• Project/repo-scoped overrides (Project-scoped overrides for the git actions settings (commit preferences, etc.) #45) become a resolution layer on the shared Settings abstraction, not a bespoke HashMap per feature.
• Automation (changelog parsing per harness, per-MCP metadata, telemetry) targets a stable schema.

Out of scope here: the exact trait shape, migration order, or which of the existing issues gets migrated first — that's the design work this issue is asking for.