benchmarks: the dense lane's ArcadeDB arms delete by vid without an index (8.1x on the delete column); add UNIQUE_HASH on vid, default off until 26.11.1, and say so on /next #291

The dense table's "delete from index" column shows ArcadeDB 8.1x the comparator median at 1M (served arm, 26.10.1). Cause: Article.vid has no index in either ArcadeDB dense arm, so each of the 5 batches of DELETE ... WHERE vid IN :ids scans the whole type. The engine itself warns that the query is very expensive and suggests an index, and JFR shows the time in record deserialization.

Measured on the laptop (A = the lane path with no index, batch 200; tools/ab.py, 95% intervals): a UNIQUE_HASH index on vid gives 0.238 [0.217, 0.256] at 1M in wall time. A Java driver with the hash index gives 0.185, and delete by RID gives 0.129. Python against Java differs by about 10% at 100k, and newest main against 26.10.1 shows no detectable difference, so this is our setup, not the engine. CAMPAIGN row 68 (the maintainers' answer on upstream ArcadeData#9169) already makes equality-only id indexes UNIQUE_HASH at the re-pin; the dense lane was never added to that registry.

1. Create CREATE INDEX ON Article (vid) UNIQUE_HASH before ingest in both ArcadeDB dense arms, behind an env switch that is OFF by default (the running 26.10.1 pass 2 must stay comparable with reps 1 to 3), stamped on the row; it is turned on for the 26.11.1 re-measure. Measure the index's ingest cost.
2. Fairness: check that every comparator's dense adapter has an index or primary key on the id it deletes by; give any that does not the same treatment, or document why not.
3. /next: a plain sentence on the dense delete cell, keyed on the rows (ArcadeDB dense rows without the stamp), saying ArcadeDB's delete ran without the id index the other tables use and that the next measurement adds it.
   CAMPAIGN row, PROTOCOL entry, and tests in the same PR.