Add owner-assisted account recovery

docs/DOGFOOD.md

@@ -65,3 +65,11 @@ application concern belongs in the shared module.
   optimistic extension serializes on the active administrator membership,
   rechecks the exact state bound into the passkey assertion, applies team and
   direct-binding consequences, and writes the audit in one transaction.
+- Human-assisted recovery cannot safely be expressed as a root command behind
+  an HTTP button. Preview 18 adds a distinct owner-assisted protocol: the
+  application performs the human review and fresh operation-bound passkey
+  ceremony, while the SQLite transaction rechecks an active direct owner,
+  invalidates every old account authenticator, stores only the grant digest,
+  and writes identity plus organization audits. Grant completion installs the
+  replacement password, passkey, and recovery-code set atomically and never
+  issues a session.

docs/GETTING_STARTED.md

@@ -26,7 +26,7 @@ The packages are ordinary Go imports. Pin the current preview and verify its
 module checksum:
 
 ```bash
-go get gamertan.com/web/requestmeta@v0.1.0-preview.17
+go get gamertan.com/web/requestmeta@v0.1.0-preview.18
 go mod verify
 ```
 

docs/MODULES.md

@@ -18,7 +18,7 @@ import "gamertan.com/web/requestmeta"
 and request the containing module at an exact version:
 
 ```bash
-go get gamertan.com/web/requestmeta@v0.1.0-preview.17
+go get gamertan.com/web/requestmeta@v0.1.0-preview.18
 ```
 
 Only imported packages are compiled and linked. The packages nevertheless

docs/ORGANIZATIONS.md

@@ -64,6 +64,15 @@ grant organization-data access. If an operator must inspect tenant data during
 an incident, use a reasoned break-glass grant. It expires within one hour and
 creates an append-only audit event in the same transaction.
 
+An application that offers owner-assisted account recovery must not infer that
+authority from a broad administration page. Use the dedicated
+`authrecovery.IssueAssistedRecovery` boundary after an operation-bound passkey
+assertion. The SQLite adapter requires a current active direct owner binding
+and active target membership in the same transaction that invalidates the old
+credentials and records the organization-visible recovery audit. Team,
+break-glass, platform, and merely descriptive roles do not satisfy this owner
+check.
+
 The SQLite adapter namespaces all tables, enforces active organization and team
 membership plus resource ancestry before accepting or evaluating a binding,
 and keeps invitations and sessions as digests. Applications remain responsible

docs/PASSKEYS.md

@@ -85,5 +85,22 @@ ceremony until expiry. A binding mismatch consumes the mismatched ceremony.
 Applications must use generic failure responses and the same credential-attempt
 rate limiting as login.
 
+Owner-assisted recovery is a third, deliberately separate path. Configure
+`authrecovery.Options.OwnerRole`, authorize an active direct organization owner,
+and bind that owner's fresh passkey assertion to the exact organization,
+target user, request identifier, and bounded human-review reason before calling
+`IssueAssistedRecovery`. The SQLite transaction rechecks the active direct
+owner and target membership, invalidates the target's password, passkeys,
+recovery codes, sessions, and pending ceremonies, then stores only a digest of
+the 15-minute grant with identity and organization-visible audits.
+
+Deliver the returned grant exactly once in a URL fragment. A public recovery
+page can pass it to `BeginAssistedPasskey` and `FinishAssistedRecovery` while
+keeping it out of request URLs, referrers, and access logs. Completion consumes
+the grant atomically with one replacement password, passkey, recovery-code set,
+and both audit trails. It issues no session. Losing the fragment after issuance
+requires another reviewed owner or root-local recovery; old authenticators
+must not become valid again as a fallback.
+
 Before enabling production mutations, applications should require at least two
 independent passkeys and complete a local recovery drill.