core: an entry named only of trailing characters makes the whole archive unextractable on Windows, with no answer possible

[otsobide]

What happens

Windows drops a trailing dot or space, and NameRules::rewrite applies that adjustment itself so the name on disk matches what the report promised. When the adjustment consumes the entire component there is nothing left, and the entry is refused as Unnameable.

plan_names runs rewrite_entry over every name in the listing, so one such entry aborts the whole plan and extract_with returns before a single byte is written. The rest of the archive is unreachable.

Reproduction

rewrite_entry("...")            = Err(... "..." becomes "", which is not a name this system can hold)
rewrite_entry("   ")            = Err(... "   " becomes "", which is not a name this system can hold)
rewrite_entry("docs/.../f.txt") = Err(... "..." becomes "", which is not a name this system can hold)

The third is the one that stings: f.txt is a perfectly ordinary file, and it cannot be extracted because of the directory above it.

Why it is different from the refusals we do want

The other refusals are questions. A character the host cannot write is something the user can answer with a substitution, and the dialog exists to collect that answer. This one has no character to substitute: TrailingCharacters is documented as an adjustment applied without asking, precisely because there is nothing to ask. So the user is shown a refusal they cannot act on, for an archive that is not malformed and that Unix extracts without comment.

Options worth weighing

• Give a name that empties out a fallback rather than refusing it, in the same spirit as DEVICE_SUFFIX for a reserved device. It has the same property: an adjustment nobody can be asked about, stated in the report rather than negotiated.
• Or keep the refusal but scope it to the entry rather than the archive, so the other entries still extract and the listing says which one was skipped. That is a bigger change, since "nothing was written" is currently a guarantee.

The first is small and consistent with what the module already does for devices.

Found while auditing the Windows CI failure that led to #88.

[otsobide]

Superseded by the naming policy that shipped in v0.10.0. Closing as a decision
rather than a fix, because the behaviour reported here is still exactly what
happens — it is simply no longer considered wrong.

Verified against main: a component of only trailing characters still stops the
whole archive. refuse_unwritable_names asks NameRules::problems per
component and returns NameError::Unwritable on the first that answers, and
"..." under WINDOWS_TRAILING answers.

What changed is the rule around it. Extraction no longer adjusts a name to fit
the host: it reproduces what the archive says or it does not happen. Under that
rule this is not a special case at all, it is the ordinary outcome for every
unwritable name, and the two fixes proposed here are both ruled out by it — a
fallback name is exactly the invented name the policy exists to prevent, and
scoping the refusal to the entry would give up the all-or-nothing guarantee that
keeps a user from ending up with half a directory they cannot tell apart from a
whole one.

The reasoning is recorded in docs/threat_model.md, measure 4b, including why
the scheme this issue assumed was replaced.

Worth reopening if the all-or-nothing guarantee is ever revisited, since this is
the case that argues hardest against it: one odd directory name makes an
otherwise ordinary archive unextractable on Windows.