Add SSH cert flows and user service installer

docs/adr/0001-single-binary-cli-and-daemon.md

@@ -12,7 +12,13 @@ The project ships one executable: `geth`. It has daemon mode with
 Control commands use a local Unix socket. There are no separate `gethd` or
 `gethctl` binaries.
 
+The same binary also owns daemon service installation through `geth daemon
+service ...`. Service installation targets user service managers: systemd user
+units on Linux, launchd user agents on macOS, and per-user scheduled tasks on
+Windows.
+
 ## Consequences
 
 Packaging and user mental model stay simple. The daemon remains the owner of
 identity, Iroh endpoint state, resources, and synchronized data structures.
+The bootstrap avoids privileged system service installation.

docs/adr/0009-ssh-trust-and-ssh-proxy.md

@@ -10,7 +10,16 @@ SSH keys are admin signing identities and ecosystem integration points. SSH is
 not a geth transport. Future SSH proxy support will carry SSH protocol bytes over
 authorized Iroh streams, and OpenSSH will still perform normal login auth.
 
+Geth also manages OpenSSH certificate request, renewal, approval, import, and
+revocation-list metadata. Signing is explicit: an approved request yields a
+concrete `ssh-keygen -s ...` command that can be run on the machine holding the
+CA key or attached YubiKey.
+
 ## Consequences
 
 Knowing an Iroh EndpointID is insufficient to reach sshd. Geth authorization must
 allow `ssh_proxy.connect` before any SSH/admin endpoint is opened.
+
+Certificate and key revocations are durable geth metadata and should be
+distributed over Iroh between authorized nodes. Discovery does not grant trust in
+certificate requests, issued certificates, or revocation lists.

docs/adr/0014-ssh-certificate-flows.md

@@ -0,0 +1,39 @@
+# ADR 0014: SSH Certificate Flows And Revocation Lists
+
+## Status
+
+Accepted.
+
+## Decision
+
+Geth manages OpenSSH certificate request, renewal, approval, import, and
+revocation-list metadata.
+
+A node may request a user or host certificate by submitting its public key,
+principals, requested validity, and optional renewal target. An authorized
+machine can approve that request. Approval does not silently sign inside the
+daemon; it returns an explicit `ssh-keygen -s ...` command that can be run on the
+machine with the CA private key or YubiKey-backed CA key. The resulting
+`-cert.pub` file is imported back into geth for distribution.
+
+Certificate and key revocations are durable records. The bootstrap stores and
+exports them as JSONL. Future work may derive OpenSSH KRL files and replicate
+signed revocation lists over Iroh.
+
+## Consequences
+
+SSH certificate lifecycle management becomes part of the SSH trust integration
+layer without making SSH a geth transport. The daemon can coordinate requests and
+distribution while the CA/YubiKey machine remains the explicit signing point.
+
+Future authorization should protect capabilities such as:
+
+- `ssh_cert.request`
+- `ssh_cert.approve`
+- `ssh_cert.import`
+- `ssh_revocation.publish`
+- `ssh_revocation.read`
+
+The current bootstrap does not claim that revocation reaches offline nodes
+immediately. Revocation distribution is eventual until stronger synchronization
+and policy enforcement are implemented.

docs/adr/0015-user-service-installation.md

@@ -0,0 +1,29 @@
+# ADR 0015: User Service Installation
+
+## Status
+
+Accepted.
+
+## Decision
+
+Geth provides `geth daemon service ...` commands to install, uninstall, start,
+stop, inspect, and print daemon service definitions.
+
+The service is always installed as a user service:
+
+- Linux: systemd user unit, `~/.config/systemd/user/geth.service`
+- macOS: launchd user agent, `~/Library/LaunchAgents/local.geth.daemon.plist`
+- Windows: per-user scheduled task named `geth-daemon`
+
+The service runs the same single binary as `geth daemon run` and preserves
+`GETH_HOME` in the service environment.
+
+## Consequences
+
+There are still no separate `gethd` or `gethctl` binaries. Installation does not
+require privileged system service access. Linux users who need the daemon before
+interactive login may still need platform-specific user-service setup such as
+systemd lingering.
+
+Future service managers can be added behind the same service-manager enum and
+CLI shape.