feat: (core) Recovery gating and sandbox eNotary

[coodos]

Summary

Support recovery options while preventing social-engineering backdoors. Friend-based recovery is temporarily gated to require passphrase.

Recovery methods

• Passphrase-based recovery:
  • eName + passphrase compare (Issue 3)
• Physical ID recovery:
  • existing implementation
• Friend-based recovery:
  • blocked unless passphrase is also provided (temporary safeguard)
• eNotary sandbox:
  • last-resort ability to write/override binding documents (not passphrase)

Recovery decision tree (with gating)

flowchart TD
 A[Recovery start: user provides eName] --> B{Has passphrase?}

 B -->|Yes| C[Passphrase recovery compare]
 C -->|Success| R[Recovered]
 C -->|Failure| F[Fail + backoff]

 B -->|No| D{Has physical ID recovery path?}
 D -->|Yes| E[Physical ID recovery existing]
 E --> R

 D -->|No| G[Friend-based recovery request]
 G --> H[Blocked: requires passphrase]

Loading

eNotary permissions boundary

flowchart LR
 EN[eNotary sandbox identity] --> BD[Binding Docs Sector Encrypted]
 EN --> AL[Audit Log Sector Append-only]
 EN -.-x PZ[Protected Zone Passphrase Hash]

Loading

Acceptance criteria

• Passphrase recovery is available and uses IP rate-limit + exponential backoff.
• Physical ID recovery remains functional (current implementation).
• Friend-based recovery is blocked unless passphrase is also provided (temporary safeguard).
• eNotary identity exists with permission to write/override binding documents.
• eNotary cannot read or write the passphrase Protected Zone.
• All eNotary actions emit append-only audit events.