docs: replace invented mount output with real transcripts; drop dead guard

[kridaydave]

Problem

The README's headline transcript is not something taproot can print. It shows a
materialized: 2.4 GB (lazy) line, a [s]ync · [f]ork · [d]etach prompt, and claims
mount blocks execution when the state has drifted. None of that is in the code.
grep -rn 'Fork\|Detach' src returns nothing, and taproot mount --no-fuse writes a
605-byte directory containing seven files. The claim that mount blocks on drift is
also wrong: drift is what taproot check and taproot sync are for.

src/util.rs also carried an unreachable guard inside validate_non_empty.

What changed

The README transcript is now the verbatim output of the current binary, with a note on
what the tree actually contains and how drift is really handled.

The dead branch in validate_non_empty is deleted. An empty path segment requires the
value to start with /, end with /, or contain //, and all three cases already
return an error above the loop. An exhaustive sweep over the alphabet {/, a, ., empty}
at lengths 1 through 6 (19530 inputs) reaches that branch zero times. The sibling
"."/".." segment check stays: the same sweep finds 1630 inputs that reach it.

No behavior changes. Every value the deleted branch rejected is still rejected, by an
earlier guard.

 README.md   | 28 ++++++++++++++++++----------
 src/util.rs |  5 -----
 2 files changed, 18 insertions(+), 15 deletions(-)

Verification

• cargo fmt --all -- --check exits 0.
• cargo clippy --locked -- -D warnings exits 0, which is the exact command CI runs.
• The deleted branch's reachability was proved by exhaustive enumeration, not by reading.

Not shipped

Three Policy fields are settable but never enforced anywhere in the codebase:
allowed_branches, blocked_env_keys, and require_check_strict. They can be written
by taproot fabric policy-set and POST /v1/policy/:repo, they round-trip to JSON, and
only require_signed is ever read (src/cli.rs:1888 and src/server.rs:75). A push to a
repo whose policy lists blocked_env_keys: ["SECRET"] succeeds today. That is a real
gap but it is a behavior change, so it is not in this PR. See the report for the
reproduction.