The rest of the mutator surface: remove, unlink retirement, remove_all, backup #621

Feature: #616 · Phase 5 of any-entry-claims.md.

1. file.remove takes target Entry — the type stops contradicting the documented contract ("file or empty directory"), and a single-entry removal works on a file, an empty directory, or a symbolic link. It keeps on_missing: unlike move, a missing target means the goal already holds, and the method produces no resource whose absence could become a nil promise.
2. file.unlink is removed and its callers move to remove — the sweep, enumerated: writ decommission (the planner's file.Unlink branch, the readback action set, and the completion tally that sums unlink+remove), test_file_unlink.star, the Go unit tests naming it, and the generated action name.
3. file.remove_all takes target Entry — rm -rf over any kind. Over a symbolic link it removes the LINK, never the designated tree: a follow is an explicit act (file.resolve), and the archival rename cannot perform one.
4. file.backup claims its source (source Entry) rather than taking a bare path — the surface's last unclaimed mutation source.
5. Policy parameters go last (the ruling): (target, prune, boundary, on_missing) — what, what else to clean up, what if it isn't there. Coupled parameters stay adjacent (boundary is meaningless unless prune is true). The audit found this touches nothing outside file.Provider.
6. file.copy, file.read_bytes/file.read_text, and file.walk_tree keep their kinds, with the reason recorded beside each so the asymmetry reads as a decision.

The removal family ends split by blast radius, never by kind — with remove's non-empty-directory guard kept as pure authoring policy: the mechanism would move a populated tree perfectly well, and the refusal exists so destroying a tree must be said, not stumbled into.