a-change-shows-the-logs-of-its-own-worktree

[VeryComplexAndLongName]

Show Logs on a change's card read only the host's own root, but a run logs where it runs — a change worked in its own worktree logs there, not in the checkout the host was opened on. So the button said "no logs" while the logs sat one directory away. Measured with the very call the button makes: listRunLogs over the host root returned 0 for remaining-groups-move-into-the-register; over its own worktree, 2.

What changes

• packages/core gains change-run-logs.ts (changeLogsRoot, listChangeRunLogs, readChangeRunLog), which resolve a change's own worktree from its name and git worktree list, and fall back to the host's root. A request names the change, never a path (ADR 0026).
• The extension's pipeline/run-logs / pipeline/run-log and the server's /api/run-logs/list / /api/run-logs/read read through it; reading one run now names its change so it is read where the list found it.
• The card of a change in its own worktree offers Show Logs, threaded the way onStart already is.

Checks

• typecheck clean, lint 0 errors; core 2303, cli 285, extension 539, server 136, webui 769 — all green. (One flaky branch-rebase git timeout passes alone; unrelated.)
• openspec validate --strict valid; no dead spec-delta drift.
• On the real data that showed the bug: the change's two runs list and the newest reads, from its own worktree.

Patch changesets for core, server, extension, webui.