Publish releases from one job; correct the server docs and crate metadata

[fylorn]

Three factual fixes.

Release notes are written once (release.yml)

The v0.47.0 release body held GitHub's generated notes four times. Every build job attached its own files with softprops/action-gh-release and generate_release_notes: true. When the release already exists, the action asks GitHub for the generated notes again and appends them to the body it found (prepareReleaseMutation: ${body}\n\n${notes}), so each job after the first added a copy. The copy count matches the job count in each release:

Releases	Jobs publishing	Copies
v0.44.0 – v0.47.0	macOS, Windows, Linux x86_64, Linux aarch64	4
v0.30.0 – v0.43.0	macOS, Windows	2
v0.11.0	one job, but the release was created by hand before the workflow ran	2
all others	one	1

Now the build jobs only build, self-check and upload their files as run artifacts. A final publish job:

• waits for every build (needs), so a failed target publishes nothing rather than an incomplete release;
• checks that exactly the listed files arrived and that each matches its .sha256 (this also runs in a rehearsal);
• asks for generated notes only when the release does not exist yet, so re-running the job after a failed upload, or tagging after creating a release by hand, does not add a second copy. Only gh's own release not found counts as missing: a network error, a bad token or a rate limit fails the step, with gh's message in the log, instead of generating a second copy for a release that exists;
• writes the release once, with fail_on_unmatched_files: true.

This also closes a window. The first job to finish used to create the release and make it releases/latest while the other platforms were still building. For a few minutes, scripts/install.sh and twcore upgrade found no file for those platforms.

Asset names are unchanged. The list now lives in the publish job, and upgrade::tests::the_release_workflow_publishes_what_upgrade_looks_for still finds every name there. The notes are still GitHub's generated list. The old comment said they came from the tag message, but the code never did that, so the comment is replaced.

Rehearsal (workflow_dispatch on this branch, publishes nothing): https://github.com/ThinkWatchProject/ThinkWatch-Core/actions/runs/36047214434. It runs every build, the artifact hand-off and the file and checksum check. It does not run the two tag-only steps. The release-exists step was run locally with gh 2.93.0 against v0.47.0 (exists: generate=false), a missing tag (generate=true), a bad token (HTTP 401: the step fails) and an unreachable proxy (the step fails).

The existing v0.47.0 release has already been edited to hold one copy of its notes. The three duplicates were removed and nothing else changed. Earlier releases with duplicates are unchanged.

Server docs: any desktop OS, and where the key is kept

• docs/server.md said the desktop app keeps the control key in the Mac's keychain. ThinkWatch Lite 2026.9.16 stores remote connection keys in connection-keys.json in its data directory. On macOS and Linux the file is 0600 in a 0700 directory. On Windows the directory's protected DACL admits only the current user and SYSTEM. The app does not use the system keychain.
• The page spoke only of a Mac. Lite on macOS, Windows or Linux connects to a remote core, so the wording is now OS-neutral. "This computer's address" matches the app's own message for a refused connection.
• docs/server.zh-CN.md gets the same corrections.
• CONTRIBUTING.md no longer calls the remote control port a transport "to come". It shipped in v0.47.0.
• CONTRIBUTING.md, Cutting a release: release.yml checks that each binary is built for its target and, where the runner can execute it, that it starts and reports the version on the tag. The Windows arm64 binary is cross-compiled on an x64 runner, so only its PE machine field is checked; the Linux binaries are also held to glibc 2.35. The list of crates the desktop app pins gains tw-link.

Cargo metadata

• [workspace.package] now sets homepage = "https://thinkwat.ch/core/" (the canonical URL; /core redirects there), documentation = "https://thinkwat.ch/docs/core/" and readme = "README.md". Every member inherits them. The crates are not on crates.io, so there is no docs.rs page. (The name tw-api on crates.io belongs to an unrelated Twitch crate.)
• keywords = ["ai-gateway", "llm", "openai", "anthropic", "gemini"] and categories = ["network-programming", "web-programming::http-server"] are inherited only by twcore, tw-gateway and tw-control. They describe the gateway, and a crate such as the YAML patch layer is not an HTTP server. Both lists follow crates.io's rules: at most five keywords, and category slugs from its list.
• tw-control description: it serves a unix socket, a loopback port on Windows, and an optional remote control port.
• twcore description: "Self-contained AI gateway: the local engine behind ThinkWatch Lite, or a standalone gateway on a server". twcore --help now takes its first line from it (#[command(about)]) instead of a separate string that still spoke only of ThinkWatch Lite.

Checks

cargo fmt --all && cargo clippy --workspace --all-targets -- -D warnings && cargo test --workspace pass locally (1581 passed, 4 ignored), with the proxy variables unset for the tests. actionlint finds nothing in release.yml. cargo metadata resolves the inherited fields as listed above.

🤖 Generated with Claude Code