sync: say why the tombstone sweep refused, instead of refusing silently

[myobie]

Step 1 of the Bluey plan. No behaviour change: the gate decides exactly what it
decided before.

The fault

The sweep forgets a tombstone only when every configured peer has acked while
this node held it. That gate is correct and load-bearing — forgetting early lets
a peer still holding the file as Present adopt it back, and the deletion loses
to the oldest copy on the fleet.

The fault was not the refusal. It was that the refusal said nothing. The only
log line sat inside if !swept.is_empty(), so "waiting on a peer" and "nothing
to sweep" were the same observation from outside. An entry could wait on one
roaming peer forever and look identical to a healthy one.

acked_through returned a bare Option, throwing the reason away at the point
it was known.

The change

ack_gate returns a typed SweepState, and every refusal names itself:

token	meaning
disabled	the sweep is off, which is the default
policy-retains	catalog keeps tombstones by design
never-sweeps-wildcard-peers	a wildcard peer set can NEVER sweep
peers-unresolved:1/2	a configured peer is not in the peer book
waiting-on:bluey	named peers, because "waiting" without a name was the gap
ready	the gate is open

The wildcard trapdoor

"*" is the obvious way to add a roaming peer to an entry. It does not make the
sweep block on that peer — it turns the sweep off entirely, because
membership is whatever peers.toml holds at that moment and a peer leaving the
book must never be what makes a deletion forgettable.

So the natural action silently disabled the feature. That case now logs at
warn and its token says it can never sweep, rather than that it merely did
not.

Reported two ways, deliberately

• fabric sync ls gains a sweep= column, so an operator asks instead of
  grepping.
• The log fires only on a CHANGE. The sweep runs on every pass; an
  unconditional line would add thousands of identical entries an hour to a
  validation log that already writes about 368 KB an hour. Making the fix bury
  its own signal would have been a poor trade.

Tests, each proved to bite

• Collapsing named waiting peers into peers-unresolved fails on "the peer
  holding the sweep up must be named".
• Reporting the wildcard as an ordinary refusal fails on "the token must say it
  can never sweep, not merely that it did not".

A second test pins the state on Silber today: Bluey is in the node peer book but
in neither sync entry — both read peers=hetz,droppy — so it cannot gate
them. Adding it to an entry would show as a named wait rather than as silence.

Wire compatibility

SyncEntryStatus.sweep carries #[serde(default)], matching the counters
beside it, so an older client decodes a newer daemon. sync ls renders
unknown rather than an empty string when a daemon predates the field, so a
missing value never reads as a state.

Verification

macOS: 233 lib, 10 provisioning, 3 sync_slice, 21 local_slice. Clippy matches
main with an empty set difference both ways, and every file I touched is
rustfmt clean. The exec.rs and node.rs rustfmt hunks are pre-existing on
main and untouched here.

That is a macOS claim; this PR's CI run is the Linux face and I read the job
steps before calling it green.