docs(person): clarify case-collision scope at the exact-case lookups (#731)

Review noted the "never throws" claim was overstated: the exact-case Optional
lookups still surface a NonUniqueResultException on two byte-identical
same-case rows. That is a true data anomaly out of #731's scope (ambiguous =
case-insensitive) and resolves to the opaque INTERNAL_ERROR, never a wrong
row. Record that boundary at both resolution points and in ADR-032 so the gap
is not silently assumed covered.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/adr/032-tag-name-resolution-tolerates-case-collisions.md

@@ -122,6 +122,12 @@ is fixed with the same exact-case-first, non-throwing pattern — but with a del
   which never matches, so a null first name resolves to **no sender**. This is pinned by a
   real-Postgres repository test.
 
+- **Scope — "ambiguous" is case-insensitive only.** Both exact-case lookups (`findByAlias`,
+  `findByFirstNameAndLastName`) return `Optional`, so two **byte-identical same-case** rows would
+  still throw `NonUniqueResultException`. That is a true data anomaly, deliberately out of scope
+  (it is not a case-collision), and it surfaces as the opaque `INTERNAL_ERROR` — never a silently
+  wrong row — so it is no worse than any other unexpected error and needs no extra handling here.
+
 - **Same stance as tags otherwise:** no `unique(lower(alias))` / `unique(lower(name))` constraint
   (collisions are valid human labels; `source_ref` is the stable identity per ADR-025), no
   merge/dedupe, code-only and reversible, and no shared `resolveExactThenCi(...)` helper — the