[Design tracker] Make rule timing and activation language predictable

[malpern]

User problem

KeyPath's rule editors do not teach one transferable mental model.

The same kinds of choices are described with different words, while some similar-sounding controls actually behave differently. Users cannot reliably predict what changing a timing value will do, transfer what they learned in one editor to another, or tell how a rule is activated. Leader and Hyper also appear as unexplained magic keys, and some community-derived names require outside knowledge.

This is a comprehension problem, not a request for a broad prose polish pass.

Desired outcome

A first-time user should be able to:

• Understand what a control changes and what increasing its value will feel like.
• Recognize the same concept when it appears in another rule editor.
• Tell what they physically do to activate any rule.
• Understand the difference between Leader and Hyper.
• Choose a rule family without knowing its community source.

Workstreams

• Explain Leader and Hyper wherever users encounter them #1202 — Explain Leader and Hyper wherever users encounter them. Shipped in Explain Leader and Hyper terminology #1207.
• Define a shared timing vocabulary for rule editors #1203 — Shared timing vocabulary approved. Implementation is split into [Timing] Make Home Row Mods and Layer Toggles mode-aware #1208, [Timing] Wire Sequence pause limit into generated configuration #1209, [Timing] Decouple Auto Shift protection from Shift hold delay #1210, [Timing] Unify Custom Rule and Mapper timing language #1211, [Timing] Explain the Chord press window and fallback tradeoff #1212, [Timing] Make Key Repeat speed direction and units predictable #1213, and [Timing] Add a shared timing glossary and align Leader/docs/accessibility #1214.
• Choose and standardize the activation-hint format for rule families #1204 — Choose and standardize the activation-hint format for rule families. Human design decision first; then split catalog/editor implementation into bounded tickets.
• Decide descriptive names for community-derived rule families #1205 — Decide descriptive names for community-derived rule families. Product naming decision first; preserve attribution and avoid internal-identifier churn unless justified.

Additional one-off string fixes should be attached to the relevant workstream or filed as focused tickets. They should not accumulate here as one large implementation batch.

Sequencing

1. Complete Explain Leader and Hyper wherever users encounter them #1202 because its terminology is already conceptually distinct and it provides immediate user value.
2. Approve the vocabulary in Define a shared timing vocabulary for rule editors #1203.
3. Create and implement timing-copy tickets by editor family, with behavior-specific tests and docs.
4. Approve Choose and standardize the activation-hint format for rule families #1204 and apply its pattern in bounded catalog/editor slices.
5. Resolve Decide descriptive names for community-derived rule families #1205 independently; it should not block clearer timing or activation language.

Completion criteria

• Each design decision is recorded in its child issue.
• Approved changes have been implemented in small, reviewable slices or deliberately declined.
• User guides and copy-focused tests agree with the shipped UI.
• No remaining editor exposes an unexplained timing term or activation mechanism identified by these workstreams.

Non-goals

• One pull request that rewrites every editor.
• Changing rule behavior as part of copy cleanup.
• Renaming internal configuration keys without a separate migration justification.

This issue is coordination-only; do not implement it as one PR.