Add mode selection state for Autocomplete vs Compose

[FuJacob]

Problem

The current suggestion pipeline assumes one autocomplete-style behavior. Compose Mode needs a first-class mode setting so UI, request construction, generation limits, and acceptance behavior can all make the same decision from shared state.

Goal

Add a clean mode-selection foundation that lets Tabby distinguish Autocomplete from Compose without scattering boolean checks across unrelated code.

Proposed Scope

• Add a persisted mode setting for Autocomplete vs Compose.
• Expose mode state through the existing settings snapshot or equivalent runtime settings contract.
• Add Settings and/or menu bar controls for choosing the active mode.
• Make the coordinator use the mode when deciding request shape and acceptance behavior.
• Keep existing autocomplete behavior unchanged when Autocomplete is selected.

Acceptance Criteria

• The selected mode persists across restart.
• Runtime code can read the selected mode from an immutable snapshot.
• UI surfaces show the current mode clearly.
• Autocomplete remains the default and does not regress.
• Tests cover mode persistence and snapshot emission.

Open Questions

• Should Compose Mode be globally selected or temporarily activated for one generation?
• Should per-app rules eventually include mode overrides?
• Should this live in current suggestion settings or a separate interaction settings model?

Parent: #66

[FuJacob]

Closing for OSS launch cleanup. Part of speculative Compose Mode epic (#66).