release: promote v0.6.0-rc1 to main (retag)

[alpCaner]

Promotes dev (3f39f34) to main so the v0.6.0-rc1 tag can point at a commit whose release.yml can actually start.

Why a second promotion

The first v0.6.0-rc1 tag failed the entire release run with startup_failure and zero jobs — run 31830969596. release.yml's python-gates granted parity.yml only permissions: {contents: read}, while parity.yml's notify-planner-drift job statically declares permissions: {issues: write}. A called workflow may never exceed its caller's grant, and GitHub evaluates that before any job runs, so the if: restricting that job to repository_dispatch never mattered.

No release object and no assets were created, so the tag was retracted under the "only retract what nothing has consumed" rule and deleted from both remote and local.

This promotion carries #752, which grants issues: write at the call site. A sweep of every local caller/callee pair now reports conflicts remaining: 0.

Content

Identical to #751 apart from that one workflow fix — same version files, same CHANGELOG section:

TAN_VERSION (source of truth) : 0.6.0-rc1
python/pyproject.toml         : 0.6.0rc1
npm-shim/package.json         : 0.6.0-rc1
CHANGELOG.md section          : ## [0.6.0-rc1] — 2026-08-14
git tag                       : v0.6.0-rc1
versions agree

Gates

#752 merged through the queue: 31 success, 0 red. The full local suite on this tree was green before the first promotion — 5126 passed, 64 skipped, 1 xfailed, parity included — and #752 changes only .github/workflows/release.yml and adds a changelog fragment.

main's required contexts were corrected in the same session: the five retired Rust checks (lint, msrv, test (ubuntu|windows|macos-latest)) were removed — their producer was deleted by this very release — and zizmor · workflow security was added to match dev.

After this

Retag v0.6.0-rc1 on the new main, then confirm release.yml starts — jobs present, not merely a run created. A created-but-empty run is what the first attempt produced.