Implement client configuration delivery and reissue lifecycle

README.md

@@ -116,3 +116,28 @@ examined. Enumeration, read, or limit failures mark the scan incomplete. The
 original files remain untouched. Adapter examples and behavior are covered with
 synthetic temporary directories in `tests/vault_import.rs`.
 
+## Client delivery and reissue
+
+`Application::prepare_new_client` stages a dual-stack peer and encrypted key.
+After a successful `commit`, `deliver_first_issue_file` can publish its first
+configuration without a vault password during that same session; a failed file
+publication can be retried to a newly selected destination. The first file is
+mandatory. `deliver_first_issue_file_and_qr` optionally returns a QR matrix from
+the same authorized bytes after file publication. Both success results carry an
+activation warning unless this session has verified the exact installed saved
+generation and its matching applied peer snapshot; historical verification and
+unknown runtime state do not suppress it.
+
+Later delivery uses `Application::reissue_client_file`, which takes the client
+public key, a password for that action, a prepared destination, and an optional
+QR choice. It freshly unlocks the installed saved vault each time, reads saved
+server/settings bytes rather than draft state, preserves validated imported
+parameters, and rejects blocked or stale records. It never reads original
+plaintext client files as a fallback. The result reports a secret-free failure
+stage and warns when the current saved peer set has not been verified as applied
+in this live session. Historical verification timestamps do not suppress that
+warning after reopen. File output uses mode `0600`, explicit overwrite
+confirmation, and separate QR failure reporting. These APIs have synthetic
+fixture coverage; the TUI password prompt and terminal QR rendering are not
+implemented.
+