Expose the skills a run actually assembled on AgentRun.status

After #157 a run's skills come from several sources (image + `subPath`, inline ConfigMap, git clone) and the loader decides the final directory from each skill's frontmatter name. None of that is visible on the AgentRun: a client can only re-resolve the Agent's refs and guess — which is what the console does today (konveyor/tackle2-ui#3546's run detail "Skills" group is a client-side join over the Agent's cards).

Two small additions would make the run self-describing:

1. **Declared, at sandbox creation** — the controller already builds `KONVEYOR_SKILL_SOURCES` (`api/skill.Source`); mirror that list as `status.skillSources`. No new RBAC, available from `Pending`.
2. **Assembled, after init** — the loader already writes `/opt/skills/.konveyor-skills.json` (`api/skill.Manifest`: skills `{name, description, type, source}` + `rules`). Have it also write a compact form (`{name, type, source}` + rule names; 4 KiB termination-message budget) to `/dev/termination-log` on success — `FallbackToLogsOnError` only covers the failure path — and have #169's termination read copy it from the init container into `status.skills` / `status.rules`. That is the ground truth for the run detail page, and what the `load_skill` tool calls in the ACP stream can be matched against ("did the model actually use skill X").

Is (1) acceptable on its own as a first step? It is a status-only change on the existing code path. (2) rides the same init-container read as #171.

Start with the AgentRun status types and the controller path that builds KONVEYOR_SKILL_SOURCES from api/skill.Source. Trace the loader's /opt/skills/.konveyor-skills.json output and the init-container termination read described in #169 and #171. Done means declared sources are available in Pending status and assembled skill and rule metadata is exposed after initialization.

Written by the indexing model from the issue text.