Define Compose Mode product behavior and safety rules

[FuJacob]

Problem

Tabby needs a clear product boundary between normal inline autocomplete and a new Compose Mode that can draft a whole comment, reply, or email. Without that boundary, long completions could feel surprising or risky because the current product teaches users that Tab accepts a small continuation.

Goal

Define the first Compose Mode behavior, trigger model, and safety rules before implementation work spreads across UI, prompt construction, runtime, and input handling.

Proposed Scope

• Define how users enter and leave Compose Mode.
• Decide whether Compose Mode is global, temporary, per app, or command-driven.
• Specify what Tab accepts in this mode and how cancellation works.
• Define maximum output length and when long insertion should require stronger confirmation.
• Identify apps or text surfaces where Compose Mode should be disabled initially.
• Write user-facing language that distinguishes Compose from autocomplete.

Acceptance Criteria

• Compose Mode has a short product spec with mode states, trigger behavior, and acceptance behavior.
• Safety rules cover accidental insertion, stale focus, unsupported fields, and app-disabled state.
• The spec names the first target writing scenarios, such as comments, replies, or email drafts.
• Follow-up implementation issues can reference this behavior instead of making separate product decisions.

Open Questions

• Should Compose Mode use the same Tab key or a separate shortcut?
• Should a preview be required before inserting longer drafts?
• Should the first version be hidden behind an experimental setting?

Parent: #66

[FuJacob]

Closing for OSS launch cleanup. Product spec, not a code issue. Part of speculative Compose Mode epic (#66).