Owner tier: the personal phone is the highest-privileged principal, and its ceremony should collapse

## Why (operator, verbatim, from the bench 2026-08-16)
"Since it is my personal phone, it should be treated as the highest privileged compute possible — personally identifiable in many ways — and should have much much looser controls and more permissiveness to build up capabilities and workflows."

The phone already IS the root of trust: it holds the signing key, it is biometrically gated, it is the operator's hand. The app currently treats it with guest-grade ceremony.

## The principle
Two different things hide under "controls":
- **Ceremony** — forms, confirmations, expirations, re-approvals. Scales with WHO you are. For the owner: collapse it.
- **Physics interlocks** — deadman, envelope caps, stop priority, refuse-not-clip, signature-at-the-moment-of-motion. These protect against BUGS, not against the owner (bench evidence same night: Auto mode ran a model's wrong draft; a cross-plugged harness swapped the axes). They do not loosen for anyone.

## What
1. **Owner principal**: the pairing holding the attestation key = Owner. (Future guest/viewer pairings get today's ceremony.)
2. **Ceremony collapse for the Owner**:
- Envelope presets: one-tap "open my usual approval" (remembered budget/window/cap) instead of the form.
- Signature lifetime for owner-signed plans: minutes, not 120 s (rationale documented against consent-freshness).
- Workflow/capability authoring (macros, gap-rail skill initiation) needs one signature, zero confirmation sheets.
- Auto mode as owner default for read/config-draft tiers.
3. **Authority migration, not gate removal**: robot-config actions keep moving from "SSH at the robot's shell" to signed host.* actions the phone can draft (the drive.trim pattern from #935). Target: capability add, model pulls, policy edits — every one a signature, none a terminal.
4. **Trust the demonstrated, not the categorical** (same philosophy as the sparse-eyes tier): gates key on what the device/operator can actually do, never on hardware class or role labels.

## Acceptance
- Owner opens a driving approval in one tap; drafts, signs, and runs a plan without a single redundant confirmation.
- Owner saves a workflow and adds a gap-rail capability entirely from the phone, one signature each.
- A guest pairing (second phone) still gets full ceremony — the collapse is keyed to the Owner principal, not to the app build.
- Every motion interlock test in CastorKit passes byte-identical.

## Pointers
- #935 (the authority-migration template), ApprovalMode.swift (Auto exists; per-tier defaults), DrivePlan.signatureLifetime (currently 2x TinyEnvelope window), FirstDrive.TinyEnvelope (preset seed), docs/SKILL-GAPS.md (consent model to extend to phone-initiated).

Start with #935 and read ApprovalMode.swift, DrivePlan.signatureLifetime, FirstDrive.TinyEnvelope, and docs/SKILL-GAPS.md to understand the existing authority and consent model. Trace how owner and guest pairings are represented before assessing the requested ceremony changes and signed host.* migration. Done means the owner workflows use the specified one-signature paths, guest pairings retain full ceremony, and every CastorKit motion interlock test remains byte-identical.

Written by the indexing model from the issue text.