Edge sync: HubIndex.Forget MUST be wired before delete_after_sync or hub-side spoke-namespace retention ships

Tracking item from the 2026-08-19 edge sync security review. Not exploitable today; filed so the hazard blocks the right future PR instead of living only in a code comment.

## The coupling

`HubIndex.Forget` (`internal/edgesync/hubindex.go:~185`) exists but is deliberately un-wired: nothing today deletes hub-side spoke files, so the receipt index never needs to forget. The hazard: if a future change adds **either**

- `delete_after_sync` on the spoke (#569 phase 3), **or**
- hub-side retention that deletes under a spoke namespace,

**without wiring `Forget`**, the hub index keeps answering "present" for files the hub no longer holds. A spoke reconcile then marks its local copy synced/prunable against data the hub silently dropped — permanent data loss on the edge box least able to recover it.

The reconciler's `confirmPresent` backend-existence check (`reconcile.go:~194`) is the compensating control today; it must not be weakened either.

## Ask

Whoever implements phase-3 delete-after-sync or hub-side spoke retention: wire `HubIndex.Forget` into every hub-side delete path for spoke namespaces, and add a regression test proving a forgotten file is re-offered by reconcile. Treat this issue as a blocker on that PR.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Read internal/edgesync/hubindex.go around HubIndex.Forget and reconcile.go around confirmPresent. Trace the future delete_after_sync or hub-side spoke-retention paths described in the issue, then identify every hub-side delete affecting spoke namespaces. Done means those paths forget deleted files and a regression test shows reconcile re-offers a forgotten file while confirmPresent remains intact.

Written by the indexing model from the issue text.