fix(attribution): credit a removal by what caused it, never by the watch's selector

docs/INDEX.md

@@ -144,7 +144,7 @@ so you never have to read a proposal to find out it already shipped.
 | [`gittarget-api-wave.md`](design/gittarget-api-wave.md) | **partly built**, filed as [#294](https://github.com/ConfigButler/gitops-reverser/issues/294). One breaking wave on `GitTarget`, of which steps 2 to 7 have **shipped**: `spec.suspend`, `status.placement` and the reconcile-request annotation in [#326](https://github.com/ConfigButler/gitops-reverser/pull/326), and B4's `commitWindow`/`commit.message` move plus the source-scope deletion in [#330](https://github.com/ConfigButler/gitops-reverser/pull/330). Organizing principle: **the folder is described on the GitTarget, the connection describes only the connection** — and this is where that became a struct boundary rather than a sentence, since grouping a field is free only in a release that is already breaking. `spec.mode` and `GitTarget.spec.interval` are both **dropped**, with re-open triggers, and `status.lastHandledReconcileAt` was dropped in the build for a stated reason. Step 8, the riders, is closed: the `CommitRequest` lifecycle hole shipped in [#400](https://github.com/ConfigButler/gitops-reverser/pull/400), the missing source-cluster provider message in [#258](https://github.com/ConfigButler/gitops-reverser/pull/258), and an asserted `CommitRequest.spec.author` is **declined** because authorship is established, never asserted ([#339](https://github.com/ConfigButler/gitops-reverser/issues/339)); #294 is closed. The reference collapse and the `scope` removal shipped in [#333](https://github.com/ConfigButler/gitops-reverser/pull/333); the `TooManyStreams` cap and the Event on a changed resolution were dropped. Also records that staying `v1alpha3` on loud rejections is a **one-consumer countdown** |
 | [`target-watch-plan.md`](design/target-watch-plan.md) | **partly built.** The diff is built and applied; removal semantics are not. The companion to [`watch-manager-ownership.md`](design/watch-manager-ownership.md): the ownership page says WHO applies a plan, this one says WHAT a plan is and what changing it may touch. A resource collection — group, resource, namespace, deliberately no served version — is the one identity the watch stream, the render-fidelity scope and the mark-and-sweep boundary all agree on, because a key that does not round-trip to the scope it sweeps under is the class of error that deletes user data. The plan is diffed into `keep`/`start`/`restart`/`stop` and applied per collection, so adding one WatchRule stops re-initializing every unrelated collection into a queue shared with other tenants; a `restart` is a served-version change, which is why the version is spec DATA rather than identity. Readiness and the fidelity revision are per scope, so a KEPT collection holds the result its own initialization produced rather than being asked to prove itself again over an unrelated edit. `stop` never touches files — removal is a Git-side sweep under the target's existing `spec.prune.mode`, not a watch-layer delete. "Cut at the producer" is the accepted consequence: nothing fences the queue, so a deselected collection may leave a short tail of writes, bounded by the queue and converged afterwards. Still open: the `stop` classification wants a settled `TypeRemoved` from `typeset` (see TODO), and removal on INTENT is undecided. |
 | [`collection-terminology-rename.md`](design/collection-terminology-rename.md) | **step 1, shipped.** Replaced cells with resource collections and removed per-rule `operations` from both rule kinds. Rules observe every object event; GitTarget prune mode controls removal. Records the rename census (760 Go identifiers, 265 documentation occurrences), the operation-filter inventory, API/Helm migration, compatibility boundaries, and test cases. |
-| [`watches-labels-simplification.md`](design/watches-labels-simplification.md) | **step 2, implemented.** After the collection rename and operation-filter removal, native per-rule `objectSelector` (#146). Kubernetes is authoritative: `Always` compares selected identities with all managed Git identities in the type/namespace scope, without comparing Git labels. Full support includes supported Kustomize layouts from the first release, plus filtered-removal attribution and ordered producer replacement. |
+| [`watches-labels-simplification.md`](design/watches-labels-simplification.md) | **step 2, implemented.** After the collection rename and operation-filter removal, native per-rule `objectSelector` (#146). Kubernetes is authoritative: `Always` compares selected identities with all managed Git identities in the type/namespace scope, without comparing Git labels. Full support includes supported Kustomize layouts from the first release, plus label-exit attribution (now selector-agnostic, see the attribution spec) and ordered producer replacement. |
 | [`label-selection-follow-ups.md`](design/label-selection-follow-ups.md) | **design, open.** What the label-selection review rounds left open, with the evidence for each: real deletions in a selected collection wait the full 3s attribution grace (the watch cannot tell them from a label exit, measured), the resync fence that stops overlapping collections from coalescing (kept on purpose), same-second overlap ties, and one store rebuild per object coming back. Also lists what was fixed on the branch |
 | [`attribution-removal-wait-options.md`](design/attribution-removal-wait-options.md) | a removal now waits for evidence about the DELETION rather than accepting the object's last write, which stopped it naming whoever last edited the object as the author of a deletion they did not perform. Enumerates the eight situations a resolution can be in and shows the cost is concentrated in exactly one: a removal for which no delete fact will ever arrive (a graceful pod delete, a status-only removal, a type the audit policy skips) spends the whole grace to return the answer it had at t=0, measured at ~3.1s against ~70ms when evidence is present. Prices five options against that, and recommends a per-route watermark — stop waiting once the fact stream has demonstrably moved past this event — over a second timeout flag whose right value lives in the API server's config rather than ours. Open: the decision, and how common the case is outside the e2e suite |
 | [`commitrequest-save-wait-options.md`](design/commitrequest-save-wait-options.md) | **design, decided** — a five-phase plan, reported from a live cluster: a `CommitRequest` can expire before the write it exists to publish arrives, because the close delay defaulted to `0` while the write is still held head-of-line waiting for an audit fact, so the save resolves `Ready=True`/`NoWindowInGrace` and the edit commits seconds later under the target's `liveTemplate`. The decision is to repair the default (`spec.closeDelay`, now a duration string defaulting to `"2s"`, **shipped as phase 0**) and then let a request **name the write it is waiting for**, reusing the `(uid, resourceVersion)` identity the attribution join already keys on, including its settled `ExactCapable` rule. Records why the fact index cannot BE the wait (it sits upstream of the watch event, so a fact-keyed wait fires before the window opens) and what to take from it anyway — the register-then-check waiter discipline, and a best-effort retrospective oracle bounded by a TUNABLE TTL. Twelve situations, and the page is deliberate about the two it cannot fix cheaply: row 11 (a saturated queue is rejected in the WATCH path and never reaches the worker, so no worker-side wait can diagnose it) is an accepted, named gap rather than a promise, and row 10 is fixed only by a hook in the fidelity-drop branch that marks a wait terminally UNSATISFIABLE — satisfying before that gate would arm a finalize for a write that never commits. Carries a **preconditions chapter** for saves on today's build (audit policy first, then delay sizing, fidelity warm-up, save-button debounce, and assert on the commit rather than on `Ready`). `CommitterActivity` is deferred, not recommended: by its own arrival-not-existence rule it cannot satisfy the already-arrived case. Open: situation 12 (one actor, two saves, one window — blocks phase 2), whether the fact-index lookup earns its coupling, and how an unsatisfied wait is graded |

docs/architecture.md

@@ -1018,25 +1018,25 @@ same `user`/`serviceaccount`/`none` vocabulary `commits_total{author_kind}` uses
 | `deletecollection_body_uid` | uid in a collection fact's set | the API server said this request deleted this object |
 | `latest` | uid (the object's own delete fact) | who removed it |
 | `name` | namespace + name | the same, for a fact with no uid (an aggregated API's usual shape) |
-| `latest` | uid (a write fact) | who last *wrote* it; a fallback for a removal |
+| `latest` | uid (a delete fact) | the object's own delete, when the sticky slot was evicted |
 | `deletecollection_scope` | namespace + selector + window | a collection request covering it was made |
 | `resource_version` | rv (the escape hatch for a fact with no uid) | a fact for this exact version, unidentified |
 | `absent` | none | nothing usable arrived in time |
 
 Three rules carry most of the behavior. **A fact about a deletion may not be replaced by a fact about
 a write:** a removal fact takes a sticky, uid-keyed slot that the ordinary last-writer-wins
-structures cannot reach, and a removal asks that slot first. That slot is the one structure the fact
-TTL does not bound: a uid is unique across space and time, so the statement cannot be superseded,
-and its horizon is the index's caps instead. It is still in-memory: a restart re-warms the index
-from one TTL of stream retention like everything else. Without the slot, a finalizer patch's fact
-overwrites the deleter's, because both carry the resourceVersion the *deletion* stamped
-([spec/attribution.md](spec/attribution.md)). **A removal never returns on a write fact
-without looking further:** the per-object tiers are last-writer-wins,
-so for a removal they hold whoever last *edited* the object, which is not who deleted it; such a
-match is held as a fallback while the wait continues for evidence about the deletion itself. And
-**an exact-capable event may not fall through to the removal tiers:** a create or update presents
-the resourceVersion its own write produced, so if the exact tier misses, the uid pointer may name an
-older, different author.
+structures cannot reach, and a removal of a terminating object asks that slot first. That slot is
+the one structure the fact TTL does not bound: a uid is unique across space and time, so the
+statement cannot be superseded, and its horizon is the index's caps instead. It is still in-memory:
+a restart re-warms the index from one TTL of stream retention like everything else. Without the
+slot, a finalizer patch's fact overwrites the deleter's, because both carry the resourceVersion the
+*deletion* stamped ([spec/attribution.md](spec/attribution.md)). **A removal is credited only to
+the request that caused it:** a write at its own resourceVersion (an object relabeled out of a
+rule's `objectSelector`) or a fact about the deletion. The object's last *edit* says nothing about
+who removed it, so it never answers, and a removal without such a fact is unresolved. None of this
+reads the watch's label selector. And **an exact-capable event may not fall through to the removal
+tiers:** a create or update presents the resourceVersion its own write produced, so if the exact
+tier misses, the uid pointer may name an older, different author.
 
 No branch on this path depends on the type. Every decision is made on the verb, on whether the event
 is a removal, and on which fields the event happens to carry. That is why an aggregated API needed

docs/configuration.md

@@ -2535,6 +2535,12 @@ the reference configuration of `1s`). The default of `"2s"` clears that; a loade
 may want `"4s"` to `"5s"`, and a save created before its writes needs the time to its first write
 on top.
 
+The floor assumes the stream is not busy. A watch stream attributes its events in order, so a save's
+edit can also queue behind an earlier event of the same type that is still waiting for its fact, for
+up to `--author-attribution-grace` each. That is rare when the audit policy covers the type, and the
+[suggested alert](interpreting-metrics.md#suggested-alerts) on `tier="absent"` says when it is not.
+Widening `attachTimeout` hides that delay rather than removing it.
+
 `maxDuration`, and `idleTimeout` when set, cover the span of the save's own writes after the
 attach. The worst case from registration to the finalize is `attachTimeout` plus `maxDuration`; the
 push follows, with its cooldown and any retries.
@@ -2761,18 +2767,19 @@ When attribution is enabled, these flags tune the join:
   below it will lose actors systematically. The wait ends the moment the fact arrives, so a generous
   grace costs latency only when a fact never comes.
 
-  **A removal is the exception, and it is worth budgeting for.** It waits for evidence about the
-  DELETION rather than settling for the object's last write, so an object edited by one person and
-  deleted by another is credited to the deleter rather than to the editor. Sometimes no delete fact
-  ever arrives, most often because the cluster's **audit policy excludes the type** (which is true of
-  every type in the recommended policy's runtime-noise list). In that case the
-  removal spends the whole grace before naming the last writer, which is the same answer it would
-  have given immediately. Measured across one e2e run, where the grace is 10s, the cost lands on
-  exactly that case and nowhere else: a removal that finds its delete evidence resolves in about
-  70ms, while one that never does averages about 3.1s before falling back. Creates and updates do
-  not consult the deletion tiers at all. The watch shard is single-threaded, so the wait also delays
-  the events queued behind it on the same `(GitTarget, type, scope)`. Lowering this flag bounds both
-  directly.
+  **A removal is the exception, and it is worth budgeting for.** It is credited only to the request
+  that caused it: its delete, or, when the object left a rule's `objectSelector`, the write that
+  relabeled it. The object's last write never answers it, so an object edited by one person and
+  deleted by another is credited to the deleter, never to the editor. Sometimes no such fact ever
+  arrives, most often because the cluster's **audit policy excludes the type** (which is true of
+  every type in the recommended policy's runtime-noise list). In that case the removal spends the
+  whole grace and then ships unresolved. Measured across one e2e run, where the grace is 10s, the
+  cost lands on exactly that case and nowhere else: a removal that finds its evidence resolves in
+  about 70ms, while one that never does waits the grace. Creates and updates do not consult the
+  deletion tiers at all. The watch shard is single-threaded, so the wait also delays the events
+  queued behind it on the same `(GitTarget, type, scope)`. Lowering this flag bounds both directly.
+  [What attribution gives up, on purpose](spec/attribution.md#what-attribution-gives-up-on-purpose)
+  lists every trade of this kind, including the one wrong author it accepts.
 
   **Watching a type your audit policy excludes costs more than attribution.** Every removal on such
   a type spends the full grace before shipping unresolved, because the fact it is waiting for was

docs/design/attribution-removal-wait-options.md

@@ -8,6 +8,12 @@
 > object's last write, which fixed a real mis-attribution. The cost is concentrated in one case —
 > a removal for which no delete fact will ever arrive — and there it spends the whole grace window
 > to return the answer it would have returned immediately.
+>
+> **Update 2026-10-22.** A removal no longer falls back to the object's last write at all: with no
+> evidence about what caused it, it is unresolved. Situations 4 and 5 below therefore end in the
+> deleter or in `absent`, never in the last writer. The cost this page is about is unchanged:
+> situation 5 still spends the whole grace. See
+> [what attribution gives up, on purpose](../spec/attribution.md#what-attribution-gives-up-on-purpose).
 
 ## The question
 

docs/design/label-selection-follow-ups.md

@@ -1,6 +1,6 @@
 # Label selection: follow-ups
 
-> **design**: open. Nothing here blocks label selection from shipping.
+> **design**: open. Nothing here blocks label selection from shipping. Item 1 is resolved.
 > Index: [`../INDEX.md`](../INDEX.md). Parent: [`watches-labels-simplification.md`](watches-labels-simplification.md).
 > Checked: 2026-09-29, against `feat/watch-object-selector` (PR #399).
 
@@ -29,37 +29,21 @@ reaches it today.
 
 ### 1. Real deletions in a selected collection wait the full attribution grace
 
-**Today.** A `DELETED` frame from a collection with a selector is a *filtered removal*. It
-resolves only on the fact at the object's exact `(uid, resourceVersion)`. See
-[attribution.md, "A removal from a label-selected collection"](../spec/attribution.md). A label
-exit always produces that fact. A real deletion never does, because a delete response carries no
-resourceVersion that matches the frame's. So every real deletion from a selected collection waits
-out `DefaultAttributionGraceWindow` (3s) and then commits unresolved.
-
-**Cost.** A stream is single-threaded, and attribution runs inline on it. Deleting a namespace
-with N selected objects therefore stalls that stream for about N × 3s. With 200 objects that is
-about 10 minutes behind, which risks a 410 and a relist. Collections without a selector are not
-affected. `gitopsreverser_watch_event_handling_seconds` shows the stall.
-
-**Why it was not fixed.** The obvious fix does not work. It would tell a deletion from a label
-exit by checking whether the frame's labels still match the selector. They do in both cases: the
-mutationlab `selector-membership` scenario measured that a label exit's `DELETED` carries the
-object as it was *before* the relabeling write. Accepting a uid-only deletion fact is also wrong,
-for the reason attribution.md gives: a relabel-out followed by someone else's delete produces
-exactly that fact.
-
-**Options.**
-
-- End the wait early once a uid-only deletion fact has arrived *and* the exact slot is still
-  empty after a short sub-grace. This is still a guess about ordering, and
-  `TestFactIndex_FilteredRemovalWaitsForADelayedExitFactPastAUIDOnlyDeletion` pins the case it
-  would get wrong.
-- Take attribution off the stream goroutine. Buffer each event with its pending lookup, and
-  release events in order as their lookups settle. The per-event latency stays the same, but a
-  burst costs one grace window instead of N. This is the real fix, and it changes the ordering
-  spec in [`watch-event-ordering-and-attribution-grace.md`](../spec/watch-event-ordering-and-attribution-grace.md).
-- Accept the limitation and document it in the configuration reference, next to
-  `objectSelector`.
+**Resolved 2026-10-22.** A `DELETED` frame from a selected collection used to resolve only on the
+fact at the object's exact `(uid, resourceVersion)`, which a real deletion never fills. Every such
+deletion waited out the grace and committed unresolved, and a prune of N objects stalled its stream
+for N x grace (it made the Flux E12 save spec fail `NoWindow`).
+
+Attribution no longer reads the selector. A removal of an object that was not terminating asks for
+a write at its exact version first (the exit), then for deletion evidence, so a real deletion
+resolves on its delete fact in about one audit batch. The one case this names wrongly, a
+relabel-out followed by someone else's delete whose fact is in the index first, is accepted and
+listed in
+[what attribution gives up, on purpose](../spec/attribution.md#what-attribution-gives-up-on-purpose).
+
+Head-of-line blocking itself is still open: an event that legitimately waits out the grace still
+delays every later event on its stream. That is ranked in
+[`open-asks-priority.md`](open-asks-priority.md).
 
 ### 2. The resync fence stops overlapping collections from coalescing