feat(run): the run step names Claude Code's run; owner=run is a built-in owner (A2)

The coupling to Claude Code's built-in run skill (wave 4, order A2,
decisions 54 and 64). The plan's "run the thing" step, the executor's
End to end part and the plan template each say in one sentence that the
app is seen and driven with run, and that the verdict is still the
End-to-end: command, because run gives no exit code. The template quotes
the name instead of backticking it: every backticked span on a template
step bullet is read as a runnable example.

R2: lib/skills/routing.mjs keeps a short fixed list of Claude Code's own
skills a quiet case may name as owner (BUILTIN_OWNERS, only run, seen in
2.1.303). For such an owner only "not taken" is checked, and the report
says so; ROUTING_NEGATIVE_WON stands, and an owner on no list is still
ROUTING_UNKNOWN_OWNER. skill-writing-criteria-quiet-2 gets owner=run.

The trekplan.md paragraph is reflowed to its old line count so the stats
line_ref there does not move (order B edits the same file); the
trekexecute Phase 9 line_ref fixture moves by two lines.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

commands/trekexecute.md

@@ -2087,7 +2087,9 @@ verification failure must not hide a manifest drift.
 
 ### End to end — "run the thing" (P9 (6))
 
-Tests passing is not the product working. Copy `end_to_end.status` from the
+Tests passing is not the product working. To see and drive the app, use
+Claude Code's built-in `run` skill; the verdict is still the `End-to-end:`
+command, because `run` gives no exit code. Copy `end_to_end.status` from the
 runner's JSON into `end_to_end` — the runner decides it, not this prose:
 
 - `"verified"` — the verification passed and at least one passed criterion

commands/trekplan.md

@@ -792,17 +792,17 @@ Write the plan following the template structure. The plan MUST include:
    (`PLAN_STEP_TESTS_ONLY`).
 
    **The "run the thing" step.** At least one step carries
-   `End-to-end: \`<command>\` → expected: <what the user sees>`: the product run
-   the way a user runs it (the CLI, the server and a request, the app; for iOS,
-   the simulator). Without it the result is "not verified end to end", never
-   green. The command passes the criteria runner's allowlist — the product's
-   own binary does not, so the run is wrapped in a script:
+   `End-to-end: \`<command>\` → expected: <what the user sees>`: the product run the way a
+   user runs it (the CLI, the server and a request, the app; for iOS, the simulator). Without
+   it the result is "not verified end to end", never green. To see and drive the app, use
+   Claude Code's built-in `run` skill; the verdict is still the `End-to-end:` command, because
+   `run` gives no exit code. The command passes the criteria runner's allowlist — the
+   product's own binary does not, so the run is wrapped in a script:
    `End-to-end: \`bash tests/e2e.sh\``. The same command is also listed under
-   `## Verification`: Phase 7 of `/trekexecute` runs that section, and a passed
-   criterion that runs the step's `End-to-end:` command is what verifies the
-   run end to end. `End-to-end:` rides on the last step that builds behaviour,
-   with `tests/e2e.sh` in that step's `Files:`: a step of its own that only adds
-   the script is a step of only tests, and it can never be proven red.
+   `## Verification`: Phase 7 of `/trekexecute` runs that section, and a passed criterion that
+   runs the step's `End-to-end:` command is what verifies the run end to end. `End-to-end:`
+   rides on the last step that builds behaviour, with `tests/e2e.sh` in that step's `Files:`:
+   a step of its own that only adds the script is a step of only tests, and it can never be proven red.
 10. **Execution Strategy** — For plans with > 5 steps: group steps into sessions
     (3–5 steps each), organize sessions into waves (parallel where independent),
     specify scope fences per session. Omit for plans with ≤ 5 steps.