docs: record the database fixes, and withdraw a finding that was my own test bug

docs/superpowers/analysis/2026-08-10-database-feedback.md

@@ -8,6 +8,24 @@ CLI on mulan: reports 2.9.0-2 to dpkg but offers the 2.11.0 relation commands
 Everything below was reproduced against the live 2.11.0 instance today. Where I
 could not reproduce something, I say so rather than passing on a rumour.
 
+## Outcome, 2026-08-11
+
+All five were addressed in 2.11.1 (`320dfca`), and item 4 turned out never to
+have been a defect at all. Verified against the live instance rather than taken
+from the commit message:
+
+| # | Finding | Outcome |
+| --- | --- | --- |
+| 1 | `relations` listed nothing | Fixed - lists correctly |
+| 2 | `relation-create` blamed the wrong argument | Fixed - names the offending argument and prints the correction to use |
+| 3 | No `unique` on `index-create` | Added - `--unique`, refused with examples when duplicates exist |
+| 4 | `find` had no limit or offset | Never broken. My error, twice - see below |
+| 5 | `password` ciphertext in version reads | Fixed - and checked in both directions, see below |
+
+On 5, the symptom is gone and the fix is not merely stuck the other way:
+`hasUnpublishedChanges` reads false on a published workflow and flips to true
+after a real edit.
+
 ## Confirmed problems
 
 ### 1. `relations` lists nothing while a relation exists
@@ -61,11 +79,29 @@ only from client code. We have three constraints we want (`users.username`,
 `users.email`, `(projectId, name)` on `workflows`) and cannot declare any of them
 until our client is upgraded, even though the server supports them today.
 
-### 4. `find` has no limit or offset
+### 4. `find` has no limit or offset - WRONG, WITHDRAWN
+
+**This finding was mine and it was wrong.** `--limit` already existed when I
+filed it; it was simply missing from `--help`, and I reported from the help text
+rather than trying it. Clearing 3,869 session documents took 39 rounds of
+find-then-remove that one `--limit` would have avoided.
+
+Worse, when I re-checked it on 2.11.1 I reported it still broken. That was a bug
+in my own test: the shell here is zsh, which does not word-split an unquoted
+parameter, so `find $C $args` with `args="--limit 3"` passed one argument
+`"--limit 3"` and the CLI ignored it. Every row count came back 100 and looked
+like confirmation. Passing the flags literally:
+
+```
+find ... --limit 3            -> 3 rows
+find ... --limit 150          -> 150 rows      (not capped at 100)
+find ... --limit 2 --offset 0 -> exec_0013ec98..., exec_001806a9...
+find ... --limit 2 --offset 2 -> exec_00217216..., exec_0028c8c0...
+```
 
-`find <collection>` returns a fixed 100 with no way to page. Clearing 3,869
-session documents took 39 rounds of find-then-remove. A `[limit] [offset]`, or a
-`remove-where`, would turn routine cleanup from a scripted loop into one command.
+`--offset` and `--eq FIELD VALUE` are new in 2.11.1, and `--help` now documents
+all of them. Nothing to fix. The lesson is mine: test the thing, do not read the
+help and infer, and be suspicious of a negative result that arrives too neatly.
 
 ### 5. Fields named `password` are encrypted in version snapshots but not in live reads