docs: correct two claims this repository makes that do not hold

[myobie]

Boundary

I authored this. Under the rule Nathan set on 2026-08-23 I may merge it only
once cos has approved this pull request and it is green. cos has not
approved it, so it waits.

What this changes

Two claims this repository makes that do not hold. Both were found by someone
following the documentation exactly. Neither is a code change — the code was
doing what it does, and the documents described something else.

1. The mode is not 644 or 755

FileMeta::executable claimed "a file is either mode 644 or 755, and no other
permission bit is replicated". The second half is true. The first half is not.

Materialization creates the file with fs::write, giving 0666 & ~umask, then
ORs in 0o111. So the mode depends on the receiving host's umask:

receiver umask	plain file	executable file
022	0644	0755
002	0664	0775

Observed on hetz and droppy on 2026-08-23: 0664 and 0775, both umask 002. cos
reported it against the sentence I had quoted at them earlier the same evening.

Only the executable bit replicates. The comment now carries the table, says
nothing may depend on the exact figure, and notes that st2's render deliberately
writes an exact mode immune to umask — so the two systems differ on purpose and
the doc should stop implying they match.

2. The checksum step has never been runnable

"Upgrading Fabric Safely" told the operator to fetch a combined SHA256SUMS.
No release has ever had one. git log -S'SHA256SUMS' -- .github/workflows/release.yml
returns nothing: the workflow publishes one .sha256 per asset and never a
combined manifest.

So the documented verification could not complete against any release this
project has published, since b7ce527 added it.

It stopped nobody until tonight, when hetz.root followed it exactly, could not
fetch the file, and refused to substitute a different checksum rather than
improvise a verification step. That refusal is the only reason this was found.

The step now fetches the per-asset .sha256 and takes field one rather than
running shasum -c, because the published file still carries the builder's
dist/ path — a check against it fails on the path, not on the hash.

The workflow is left alone. It was never wrong; the document described a
release layout that never existed. I considered adding a combined manifest to
match the doc and rejected it: changing release output to fit a sentence is the
wrong direction when the sentence is the thing that is untrue.

How these were found

Not by review. Both surfaced because an operator did exactly what was written
and the system did something else — which is the only way this class of defect
ever surfaces.

Verification

Documentation only, in a doc comment and a README. No behaviour change. 233 lib
tests pass and manifest.rs is rustfmt clean.