docs(release): put the export fix and the status row into 0.5.0 (plan r12, part 8) - #20

Summary

#18 and #19 are on main. This PR puts them into the 0.5.0 release page. The release workflow cuts the ## [0.5.0] section of CHANGELOG.md for the GitHub Release, so both entries must be in that section before the tag.

 ## [Unreleased]
-### Fixed
-- **`zypi export <id>` works with the Python agent (TUI)** ...
-### Changed
-- **The status row is drawn with the Python agent (TUI)** ...
-## [0.5.0] - 2026-10-12
+## [0.5.0] - 2026-10-13
 ### Fixed
   ...
+- **`zypi export <id>` works with the Python agent (TUI)** ...
 ### Changed
   ...
+- **The status row is drawn with the Python agent (TUI)** ...
 ### Known issues
-- **`zypi export <id>` cannot read the sessions of the Python agent** ...
-- **`[ui.status_line]` draws nothing** ...
+- **`[ui.status_line]` has no `context` or `cost` items with the Python agent** ...

The rest is the record, in documents only:

CHANGELOG.md                       the diff above
docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md
                                   exit conditions 1-3 on the final tui/ tree, decisions 6 and 15
                                   (done, merged), known issues, next steps, links to #18 and #19
docs/PLAN/archive/...-EXECUTION-LOG.md
                                   part 8: what was checked, what was merged, the results
docs/baselines/tui.md              new release size and build time

No code, no workflow, no package changes.

Evidence

• Before: the [0.5.0] section is 45,855 B. The two entries sit under [Unreleased], so the release page would not show them. The known issues would say that zypi export does not work and that the status row draws nothing. Both are no longer true.
  After: the same awk program as in release.yml, on the LF text of CHANGELOG.md: 49,429 B, five groups (Added 16, Fixed 32, Changed 14, Removed 2, Known issues 6). The two known issues about zypi export and about the status row are gone or narrowed; [ui.status_line] now says that context and cost stay empty with the Python agent, which is what feat(tui): the status row is drawn from what the client knows #19 does.
• Checks on the tree that the tag will have. This PR changes documents only, so tui/ and packages/ stay the tree of 9058ab3. On that commit: CI and TUI CI pass. Gates + cargo check: warnings 0, leader 245 of 245, x.ai 304 of 304, graph 980 of 980. cargo test: 8,700 passed, 0 failed, 22 ignored. The same numbers came from the runs on 1fa18cf before the merge.
• Release size (release_baseline run 38353042677, on 1fa18cf, the same tui/ tree): zypi 420,667,200 B. The limit is 470,461,776 B (v0.4.0). Cold build 1,194 s. --version median 22.9 ms.
• Release dry run (run 38353038777, on 1fa18cf): success in 30 m 46 s. Python packages, Linux x86_64 and macOS arm64 builds pass. publish-pypi and github-release are skipped, as designed for a manual run.
• ruff check . and ruff format --check . pass. I did not run pytest or cargo test on my machine again, as the owner asked. This PR does not change a line that they run.
• Not verified: nobody has started the macOS binary (the dry run only shows that it builds). There is no Windows binary. The publish steps (PyPI and GitHub Release) run only for the real tag.

Merge Danger

Door: two-way

Only text changes. A revert puts the old text back. The tag that follows this PR is not two-way: a version on PyPI cannot be replaced. This is why the PR is checked on the release tree first.

Blast Radius: release notes

The text of the GitHub Release page for v0.5.0 and the plan documents. No code runs differently. TUI CI does not start for this PR (its path filter has no document path); CI does.