docs(reviews): re-verify doc-only Server-0xx resolutions; re-fix regressions

Audited every Server-0xx finding whose Resolution described a
documentation-only or comment-only change, and spot-checked the doc
sub-claims of otherwise test-backed resolutions. 20 entries annotated
in place (append-only; no historical resolution text rewritten).

Two corrections had not survived and are re-applied:

Server-040: the MapGroupsToRoles lookup-precedence comment moved intact
into DashboardGroupRoleMapping (792e3f9) and was then deleted wholesale
by fca978d, a sweep meant only to strip (Server-NNN) tracking markers.
That also removed a later, substantive paragraph recording that the
shared ZB.MOM.WW.Auth.Ldap provider pre-strips groups to short RDN
names, so a full-DN GroupToRole key is unsupported. Both paragraphs
restored, minus the tracking IDs.

Server-009: the WAL / busy_timeout note vanished when the Storage
section of docs/Authentication.md was rewritten to delegate
connection-factory detail to ZB.MOM.WW.Auth.ApiKeys. The behavior is
still live in the library (confirmed against 0.2.1), so the fix is
prose-only.

Server-011/014/022/023 are annotated as moot rather than regressed:
the IAlarmRpcDispatcher trio was deleted in dc9c0c9 and no stale
'not yet wired' / 'PR A.6/A.7' prose survives in Server source.
Server-038's documented v1 ACL gap was later closed by
IDashboardSessionAcl, so its remarks are current.

Comment/doc-only; no logic changes.

docs/Authentication.md

@@ -175,6 +175,17 @@ optional serialized constraints, and the `created_utc`, `last_used_utc`,
 belong to `ZB.MOM.WW.Auth.ApiKeys`, this document does not restate their column
 readers or SQL; consult the library for that detail.
 
+One connection-level behavior is worth stating here because it is what keeps the
+store usable under concurrency rather than an implementation detail of the schema:
+the library's `AuthSqliteConnectionFactory.OpenConnectionAsync` opens pooled
+connections with a non-zero command timeout and applies `PRAGMA journal_mode=WAL`
+and `PRAGMA busy_timeout` (5 s). Last-used stamping runs on every authenticated
+request and the audit store appends on every denial, so without WAL and a busy
+timeout those concurrent writers would surface `SQLITE_BUSY` as a hard failure on
+the request path instead of degrading gracefully. WAL is a persistent
+database-level setting, so re-applying it per connection is a cheap no-op;
+`busy_timeout` is per-connection state and must be set each time.
+
 ### Audit trail
 
 The library emits its own API-key audit entries (from the admin verbs — create,