refactor: store the GitHub token through keyring 4's native stores and sort the docs by reader

[MotherSphere]

Two things the org conformity plan grouped together: the last major dependency still behind (keyring 3 to keyring 4), and the README and docs/ brought to the org template, now that the Preferences rebuild (#95) has shipped and the docs can describe it.

Keyring 4

keyring 3.6.3 (with the apple-native, windows-native, sync-secret-service and vendored features) is replaced by keyring-core 1.0.0 plus one store crate per OS, each gated to its own target and pinned to a full version:

OS	Crate	Where the token lives
macOS	apple-native-keyring-store 1.0.2 (keychain)	the user's login Keychain, generic password, service colony-launcher, account github-oauth
Windows	windows-native-keyring-store 1.1.0	Credential Manager, target name github-oauth.colony-launcher
Linux and BSD	dbus-secret-service-keyring-store 1.0.1 (crypto-rust, vendored)	the Secret Service default collection, attributes service=colony-launcher, username=github-oauth

The fallback file stays <config dir>/auth/github_token.json (on Linux ~/.config/Colony/Colony/auth/github_token.json), mode 600.

• No mock outside tests. Colony never calls set_default_store. Every save, load and logout builds its entry from os_store(), which has one arm per target and no fallback arm, so a target without a store is a build error rather than keyring 3's silent in-memory mock.
• The plaintext file goes only after a verified round trip. store_verified writes the token, reads it back, and only an identical read-back deletes the file. A write that answers Ok but keeps nothing (keyring 3's trap) or a refused write keeps the 0600 file and logs why.
• Tokens saved by keyring 3 are still read. I checked the sources of both versions: the three stores use the same service, account and Windows target name as keyring 3, and the Secret Service store finds keyring 3's item by service and username and updates it in place. No legacy read-and-restore step is needed.
• Tests (mock store, in tests only): the native store is selected per target and is never the mock, a verified save deletes the plaintext copy, a forgetful write and a refused write both keep it (mode 600), logout clears both copies and accepts an empty store.
• I chose the libdbus store over the zbus one: it keeps the client keyring 3 used and does not pull in the zbus stack. The keyring 4.2.0 crate itself is not used, since the plan asked for keyring-core and the store crates directly.
• MSRV: no keyring 4 crate raises rust-version above 1.88. The highest, windows-native-keyring-store 1.1.0 and dbus-secret-service-keyring-store 1.0.1, declare exactly 1.88.
• cargo tree -i openssl-sys --target all -e normal is still empty.

Docs sorted by reader

docs/ now follows templates/program/docs/README.md:

Before	After
docs/docs.md	deleted, replaced by docs/README.md (the index)
docs/tutorial.md	docs/guide/tutorial.md
docs/faq.md	docs/guide/faq.md
docs/colony-spec.md	docs/guide/colony-spec.md: its readers are app authors, who use Colony as a platform rather than read its code
docs/architecture.md	docs/internals/architecture.md
docs/release-signing.md	docs/internals/release-signing.md (moved only; #93 already corrected its content)

Links are fixed in the README, CONTRIBUTING.md and the source comments (src/signing.rs, src/github/releases.rs, src/github/mod.rs, and the doc-parity test message in src/ui/theme.rs). The issue templates link no doc page. Inbound links from the rest of the org: gh search code for Colony/blob/main/docs, colony-spec.md and release-signing.md across Project-Colony finds none outside this repository.

README

Rebuilt on templates/program/README.md: a centred header with a light and a dark logo (redrawn from the three-hexagon mark of assets/icons/icon.png at 512 and 1024 px, so it stays sharp), the tagline, License, Platforms (to #installation) and the two AUR badges, the intro, the Status blockquote, then Why Colony, What it does, Installation (AUR, direct download, build from source), the Colony-specific sections, Documentation, Code signing policy with its Privacy policy, and License.

• The Status says what is proven, and that the shared sign-and-publish workflow has not yet published a Colony release (v0.10.4, the latest, came from the workflow ci(release): sign and publish through the shared workflow #87 replaced), that SignPath is pending, and that a broken Colony release blocks every other program's release.
• The Code signing policy now carries the template's file table and openssl commands. The SignPath sentence and the team roles stay, since the SignPath application already points at them, and the ### Privacy policy heading keeps its anchor for the same reason.
• The Privacy policy keeps the network inventory and adds what is stored locally: preferences and favourites, the token in the OS credential store with the fallback file, the caches, the log, installed apps, and the Linux menu entries.
• Removed: the screenshots template comment, and the claim that a release is published after each merged change.

Stale statements corrected

• The FAQ said signing in gives access to private repositories (twice). The scope is read:user, and the catalog is the organisation's public repositories.
• "Settings" and "Settings, GitHub tab": the page is Preferences, opened from the Colony name in the sidebar, and GitHub is a sidebar button whose panel has Sign in and Sign out.
• CONTRIBUTING.md pointed at the old cache path; it is ~/.cache/Colony/Colony/repos_cache.json.
• Categories are taught in their canonical lowercase form, and every full colony.json example carries $schema.
• The FAQ claimed a 300 s download timeout (it is 60 s without data, with no total limit), scan directories in preferences.json (they are in colony.toml), and a D-Bus session as a launch requirement (without one, the token falls back to the file).
• The build no longer needs libgtk-3-dev, libxdo-dev, libdbus-1-dev or pkg-config: nothing links GTK or xdo, and libdbus is compiled from source. The README and CONTRIBUTING now say Rust 1.88 and a C compiler. The release workflow no longer installs them either: the Linux release build runs on the same ubuntu-latest runner that ci.yml already builds on without them.
• "All" lists the catalog, not the catalog merged with local apps; the system section does that. Colony writes its own menu entry for each app on Linux.

CONTRIBUTING.md still names {{APP_NAME}}: that is the instruction to replace the placeholder in the release template, not leftover template text.

Checks run locally (Linux)

• cargo fmt --all -- --check, cargo clippy --locked --all-targets -- -D warnings: clean.
• cargo test --locked -- oauth doc_parity: 6 passed.
• The macOS and Windows os_store arms compile: a scratch crate with the same function and dependencies passes cargo check --target aarch64-apple-darwin --target x86_64-pc-windows-msvc.
• Every relative link in the README, CONTRIBUTING.md and docs/ resolves.