docs(v2.11.0): relations + unique constraints; require an explicit CMAKE_BUILD_TYPE

Records the full v2.11.0 surface and its deliberate limits, and the process
lesson from the branch: fourteen implementer reports contained a verification
claim that proved false, including one of my own, and the claims that held were
the ones verified by reverting the fix and observing the failure.

Also fixes the documented build command. Without -DCMAKE_BUILD_TYPE, CMake picks
no build type and produces an unoptimised binary that behaves materially
differently from the released one - three separate measurements of test_eviction
disagreed before anyone noticed the two build trees were configured differently.

VERSION

@@ -1 +1 @@
-2.10.0
+2.11.0

docs/ROADMAP.md

@@ -1,6 +1,6 @@
 # Smartbotic Database - Status and Roadmap
 
-**Current version: 2.10.0** (see `VERSION`). Last reviewed: 2026-08-09.
+**Current version: 2.11.0** (see `VERSION`). Last reviewed: 2026-08-10.
 
 This is the single authoritative statement of what exists and what does not.
 If any other document in this repository disagrees with this one, this one is
@@ -53,7 +53,7 @@ Consequences of that substitution, which trip up readers:
 
 ## Shipped
 
-Every item below is in the installed product as of 2.10.0. `CLAUDE.md` has the
+Every item below is in the installed product as of 2.11.0. `CLAUDE.md` has the
 detail and the failure modes.
 
 - JSON document store: collections, version history, field-level encryption, TTL
@@ -66,6 +66,10 @@ detail and the failure modes.
 - Per-listener TLS and bearer-token auth
 - Durable snapshots with tiered recovery and read-only lockout
 - Replication, events/subscribe, migrations, set operations
+- Referential integrity: relations with restrict / cascade / set_null / no_action,
+  a DUPSORT reverse index, `DescribeDelete`, `relations check`, per-collection
+  enforcement switches, and TTL expiry running the same policy as a manual delete
+- Unique constraints, enforced inside the document's own transaction
 - Paging fast path (no filter, no sort) and the two-pass filtered/sorted scan
 - Secondary indexes on declared fields: equality, IN, CONTAINS, EXISTS,
   ranges, intersection, result ordering, filtered totals, and distinct
@@ -136,35 +140,28 @@ This is the v2.x arc's architectural endpoint. It touches the write path that
 produced the v2.4.3, v2.4.4 and v2.8.0 LMDB handle incidents, so it wants to land
 in small reviewable pieces with the sub-db identity sentinel kept intact.
 
-### 5. Relations, and unique constraints - one piece of work
-
-Referential integrity does not exist: deleting a parent leaves children pointing
-at nothing, silently, with no way to detect it. `smartbotic-automation` has
-`workflows` referenced by `executions`, `users` by `sessions`, and `credentials`
-from node configuration.
-
-**The design is re-validated and current** as of 2026-08-09:
-`docs/superpowers/specs/2026-08-03-relations-design.md`. Read its status section
-first - it lists what survived re-validation, what was wrong, and the constraints
-that post-date it. **The plan to execute is
-`docs/superpowers/plans/2026-08-09-relations-v2.11.0.md`** (13 tasks, Phase A
-additive and shippable alone, Phase B the write-path work). The 3278-line
-`2026-08-04-relations-v2.5.0.md` beside it is superseded and must not be executed.
-
-**Relations and unique constraints share one blocker**, so schedule them
-together. Both need `LmdbDocumentStore` operations to accept a caller's
-`WriteTxn` - relations for atomic cascade across parent, children and index
-sub-dbs; uniqueness so a rejection can propagate instead of being swallowed by
-`applyDualWriteMirror`, which currently catches every exception, bumps mirror
-drift and flips `mirror_healthy_` (the v2.8.1 fault). MemoryStore also mutates
-before the mirror runs, so a clean rejection needs the in-memory write rolled
-back. The uniqueness check itself is already built and tested, sitting unreachable
-behind that.
-
-Also requested and specified: **per-collection enable/disable** for relation
-enforcement and uniqueness, persisted in `CollectionCfg` alongside
-`versioningEnabled` and `indexedFields`, and re-armed at boot the way
-`applyIndexDeclarations()` already does.
+### 5. Relations - what is left after v2.11.0
+
+Shipped in v2.11.0; see the `CLAUDE.md` entry for the full surface. Remaining,
+all deliberate and none blocking:
+
+- **`restrict` is checked one level deep.** A cascade that would destroy a
+  `restrict`-protected grandchild is refused rather than recursing. Recursion
+  needs an unbounded transaction and its own WAL-first story.
+- **A cascade that fails after its WAL fsync still applies on the next restart.**
+  Inherent to WAL-before-LMDB; documented in `relation_cascade.hpp` and the error.
+- **One narrow race remains:** a write extending a TTL *during* a cascade's
+  fsync-plus-commit. Only reachable for a `cascade`/`set_null` relation whose
+  parent collection carries a TTL and is renewed after expiry. The fix is a
+  per-document claim flag that makes the concurrent write lose visibly - **not** a
+  versioned delete, which does not close it (no version-checked delete primitive
+  exists, and the cascade never goes through `remove()`).
+- **Cascade is unbounded in memory and transaction size** for a very wide parent;
+  a pre-flight child-count cap would bound both.
+- `_relations` has no direct-document-write interception, unlike `_policies`, so
+  an admin editing the declaration by hand has no effect until restart. A
+  replication follower likewise does not re-arm until restart.
+- No reserved `_`-prefix check on relation names.
 
 ### 6. Smaller known gaps