docs: add automation and encounter design implementation plans

[prodmodfour]

Summary

Adds the complete implementation sequence that follows the existing Ability automation plan without changing or interrupting that work:

1. ABILITY_AUTOMATION_PLAN.md finishes as currently defined.
2. AUTOMATION_PRESENTATION_CONTRACT_PLAN.md establishes the source-agnostic action, passive, choice, pending-response, explanation, accepted-presentation, privacy, realtime, and recovery contracts.
3. CAPABILITY_AUTOMATION_PLAN.md covers the full canonical capability catalog, including valued movement, passive facts, activated/contextual rules, geometry, senses, forms, crafting, campaign time, and typed GM adjudication.
4. EDGE_AUTOMATION_PLAN.md separately covers Trainer Edges and a newly frozen app-owned Poké Edge catalog, with prerequisite/build validation, typed instances, grants, passives, triggers, campaign operations, and migration.
5. FEATURE_AUTOMATION_PLAN.md covers source repair, classes/branches/ranks, AP Bind/Drain, Orders, Training, triggers, Stratagems, Weapon Features, permanent grants, capture, crafting, research, social, travel, and downtime.
6. ENCOUNTER_UI_UX_PLAN.md implements the Battle Cockpit, source-agnostic action dock, decision layer, resolution stack, battle stage, progressive spatiality, tactical lens, GM Director layer, Encounter Builder, accessibility, responsive design, performance, rollout, and retirement of map-first live play.

Also adds DESIGN.md as the normative product and visual-design authority. It defines Rotom Table as a living field terminal; establishes Field Guide, Workshop, and Live Encounter contexts; and specifies semantic colour, surfaces, shape grammar, typography, component anatomy, encounter choreography, motion, accessibility, responsive behaviour, authority/latency presentation, forbidden patterns, and governance.

Planning guarantees

• Every plan has a durable status/current-ticket header, dependency gate, completion contract, architecture, update protocol, progress snapshot, sequential tickets, release acceptance, and decision log.
• The five ledgers contain 460 sequential implementation tickets with no gaps or duplicates.
• Capabilities, Features, and both Edge families include source-freeze/source-repair phases before semantic cohort work.
• Passive and derived mechanics are explicitly prevented from becoming generic action buttons.
• Source kind remains provenance rather than mandatory UI taxonomy.
• The first encounter-workspace slice remains map-backed; a first-class Encounter document is introduced only after the boundary is proven, avoiding dual authority.
• Existing map preparation and the Three.js renderer are preserved as the Battlefield Workshop and tactical lens.

Files

• AUTOMATION_PRESENTATION_CONTRACT_PLAN.md
• CAPABILITY_AUTOMATION_PLAN.md
• EDGE_AUTOMATION_PLAN.md
• FEATURE_AUTOMATION_PLAN.md
• ENCOUNTER_UI_UX_PLAN.md
• DESIGN.md

Validation

• Verified ticket identifiers are continuous and unique within every ledger.
• Verified all ticket states use the existing plan vocabulary.
• Compared the branch to main: six added documentation files, 2,105 lines, no runtime-code changes, and no branch divergence.
• Runtime tests were not run because this PR changes documentation only.