DELETE cost on indexed ledgers: a constant object over many subjects, and one value of a wide slot #2087

Since #2008, a DELETE retracts only facts it reads from storage, which is what fixed the phantom retractions, and it means a DELETE reads where it didn't before. bplatz's follow-up commit on #2008 (007aa2983) made the wide-slot case linear by indexing each slot once (232 to 27 ms for a JSON-LD delete at 8,000 values). Two shapes still pay more for the read than they need to.

• A constant-object DELETE over many subjects reads one slot per subject: 1.09–1.13× what it cost before fix(transact): retractions name stored facts; RDF text is parsed once #2008 on an indexed ledger, where the old code committed phantom retractions without reading. One POST read per (predicate, object) pair would serve every subject. It needs a novelty read by pair beside today's per-slot one, and a bound for popular pairs, where one POST read would scan every subject holding the value while the DELETE names only a few.
• A DELETE that names one value of a k-value slot reads the whole slot, so its cost grows with the slot's size rather than with the values named. It measured that way during fix(transact): retractions name stored facts; RDF text is parsed once #2008's review, on an earlier head; I haven't re-measured it on main. Point reads of (s, p, o) per named value, when a wide slot gets only a few intents, would make it O(log k): values whose index key can merge terms need a by-key lookup, and list positions and the k-th identical witnessed row need care, so this wants a prototype and a measurement, with a bound on when value reads pay.

From #2008 (Follow-ups: a constant-object DELETE over many subjects) and its review (the one-value delete).