feat(core): revoking a share by itself (T76)

[haiquang9994]

Roadmap task T76 — a share that ends by itself, the manual path having landed with T74.

What it does

• A network change disables sharing and says why. One loop shaped like certs::renewal::start,
  [sharing] check_seconds defaulting to 30. A finding must survive two consecutive passes before
  it revokes: interfaces() returning Err is no information, not evidence of a change. The
  revoke calls Sites::unshare rather than a second copy of it, so the automatic path and the
  manual one are the same road.
• --for 2h, measured against the shared_since T74 already stores, kept as a property of the
  share in a new shared_until column. A deadline already past is refused rather than honoured.
• Sharing on the event stream: one DaemonEvent::SiteSharingChanged carrying a SharingChange
  of Requested, Expired or NetworkChanged { was, now }, so a client can surface it.
• Two enforcement tests. The web-ports-only scan, which proves what a shared home listens on
  and says plainly that it proves nothing about the firewall; and the rule-by-label test, which is
  Windows-only because ufw has no comment field to name a rule of ours with.
• The rule MixEngine never made. Binding UDP 5353 makes Windows raise its own dialog, whose
  Allow writes an every-port TCP+UDP rule for mixengined.exe — wider than "web ports only", not
  made through mixengine-elevate, and not removed by site.unshare. Decided: bind the responder
  late so the prompt is not pre-empted, refuse to answer it on the user's behalf, and report the
  rule as a Note in mix doctor rather than pretend it is not there.

What it also fixes

Caddy was installing a certificate authority of its own into the user's trust store, and
MixEngine was letting it. auto_https off stops Caddy obtaining certificates and says nothing
about its own local CA, whose root it installs on first provisioning — five CN=Caddy Local Authority roots were found in CurrentUser\Root on the machine this was written on, none asked
for. That is the design MixEngine spends T48 and T49a establishing, undone by a default.

It surfaced as this task's port-scan suite timing out on the Windows runner: both servers reach
server running, the install then blocks on a consent nobody is there to give, and the readiness
probe's one unbounded request never comes back.

The first fix was skip_install_trust alone and it did nothing — the adapter applies the option to
the authorities a configuration names and names none on its own, so the CA provisioned at run time
was still the implicit, installing one. The fix is that line plus a pki { ca local } for it to
apply to, asserted against Caddy's own adapter rather than against the rendering.

Not done here: removing the five roots already on the development machine. Windows refuses without
interactive consent, and a tool deleting trust anchors on somebody's behalf is the other half of the
same mistake.

Testing

CI green on all three systems, including both real-server steps. Locally: fmt, clippy -D warnings, rustdoc -D warnings, check --release, and 96 test suites.