core: refuse an entry name this system cannot write, instead of renaming it

[otsobide]

Extraction used to negotiate over a name the host could not write. A refused
character became a question for the user and was replaced with their answer; a
trailing dot or space was truncated in silence; a reserved device name gained a
_. The entries were then written under whatever that arrived at.

It worked, and what it produced was a directory tree whose names this program
had invented. what?.txt landed as what_.txt and CON.txt as CON_.txt, and
nothing afterwards — not the returned listing, not a later collapse compress
of the same folder, not the person reading it a month later — could tell which
names came from the archive and which from us.

An extraction now reproduces what the archive says, or it does not happen.
refuse_unwritable_names judges the whole listing against NameRules::can_write
before the first byte and fails on the first component the host cannot hold
exactly as spelled, naming the entry, the component and the reason:

the archive entry "docs/notes.txt." cannot be written on this system:
"notes.txt." ends in ".", which this system does not preserve.
Nothing was extracted; extract it on a system that can hold the name.

The four faults have one ending now. Nothing is written at all, so an entry that
was perfectly writable does not arrive either — that is the half worth keeping,
and every rewritten test asserts it.

On Linux nothing changes in practice: NameRules::unix() refuses only the NUL
byte. This is a Windows-facing change.

Closes

These keywords will not fire on this merge, and that is expected. GitHub
only interprets closing keywords when a pull request targets the repository's
default branch, and this one targets dev. The issues below therefore stay
open when this merges, by design rather than by oversight.

Whoever cuts the next release: carry Closes #95 and Closes #91 into the
body of the dev -> main pull request. That is where they fire, and it is
the only hop in this flow where they can.

Closes #95 — the names the user approved are not provably the names extracted.
There is nothing to approve. unwritable_names is advisory, and the listing
extract_with judges is the one it extracts, so the two-read gap has no
subject.

Closes #91 — the collision guard compares planned names byte for byte. The
guard is gone: with nothing renamed, a collision cannot be manufactured, and the
case the issue calls worst (WHAT?.txt answered with _ landing on an existing
what_.txt) is unreachable. One residual the issue documents is not fixed and
deserves a narrow successor: two entries of the archive's own differing only in
case are still both written, the second over the first on a case-insensitive
filesystem, with the listing naming two files where the disk holds one. That
half predates this and was explicitly allowed before too.

Supersedes #90 — an entry of only trailing characters makes the whole archive
unextractable. Verified still true, and now intended: it is the policy for every
unwritable name. Both fixes the issue proposes (a fallback name; scoping the
refusal to the entry) are rejected by this decision, which is recorded in
threat_model.md §4b. Worth closing by hand rather than by keyword, since it is
a decision and not a fix.

What is deliberately left behind

Substitutions, ExtractOptions::with_replacements, NamePlan, the
extract_*_planned backend variants, tar's second write path, the CLI's
adjustments/Adjustment and Outcome::Extracted { adjusted }, and the
desktop's whole naming dialog with its unwritable_names command are all inert
and documented as such.

Removing them is follow-up, kept out of this PR on purpose: tar's second write
path carries the containment guard, and it should not move in a change about
naming. Deleting the public surface would also have stopped the test crates
compiling, and tests that fail to build cannot show what a policy change costs.

Tests

No test was deleted to make this pass. Five in apps/core/tests/names.rs, two in
apps/core/tests/security.rs, two in apps/cli/tests/names.rs and four in the
desktop suite were rewritten to assert the refusal, each keeping the guarantee it
was written for. Two cases were absorbed by table-driven replacements.

Two are worth pointing at:

• an_answer_no_longer_rescues_an_entry_the_host_cannot_write is the old
  answer-validation test turned around. Its subject is gone, so it now guards
  the thing most likely to be quietly undone: the most reasonable answer to the
  most ordinary question this ever asked must still extract nothing.
• a_name_that_needs_no_answer_is_adjusted_rather_than_refused was passing
  while asserting the opposite of what the product does. It exercised a pure
  function that still works, under a name describing behaviour that had been
  removed. Rewritten to pin the criterion the CLI actually uses.

Documentation

threat_model.md measure 4b is rewritten around the narrowing and keeps the
reason for it, since the scheme it replaced looked like the kinder answer and
somebody will propose it again. Measure 4a loses the paragraph about following
the planned name. architecture.md and desktop.md follow.

A sweep of every internal link, anchor, cited file path and cited test name
across all eight documents came back clean apart from three gaps this branch did
not cause, fixed in 6043c07: --verify was undocumented for the CLI (along
with the fact that every local compression is already read back, and the flag
only chooses how deeply), test (desktop, rust) was missing from the CI section,
and the README's test counts were stale before this branch as well as after.