add linked sshsigchain v2 core

docs/adr/0018-sshsigchain-v2.md

@@ -0,0 +1,41 @@
+# ADR 0018: Linked SSHSIGCHAIN v2
+
+## Status
+
+Accepted for the new generic core and geth keychain profile. Legacy static
+sigchain publication is deprecated pending explicit v2 command migration.
+
+## Context
+
+The prior static JSONL keychain flow replayed records after sorting mutable
+timestamps and used a downloaded allowed-signers projection to verify its own
+checkpoint. That permits self-bootstrapping trust and makes revocation,
+rollback, and fork semantics inadequate for a trust foundation.
+
+## Decision
+
+Geth adopts SSHSIGCHAIN v2 as the replacement design:
+
+- root trust is an explicit `(chain ID, profile, namespace, root key)` tuple;
+- records are linearly ordered by sequence and linked by a digest over their
+  signed content and SSHSIG signature;
+- the initial root is only a genesis requirement, not a permanent bypass;
+- profile authorization runs against the causally preceding state;
+- key lifecycle is represented by causal add/revoke records, not timestamp
+  validity fields; and
+- payloads use deterministic binary codecs with a strict round-trip check.
+
+The generic core is transport-independent. Geth continues using Iroh for all
+node-to-node communication; SSH remains an identity/signature integration and
+not a geth transport.
+
+## Consequences
+
+The v2 core can be published and implemented by applications without importing
+geth's resource model. Geth's keychain profile is intentionally narrow and
+tested against self-bootstrap, fork, and backdated-revocation attacks.
+
+Existing static v1 bundles cannot safely migrate in place. Operators must pin a
+new v2 trust tuple and create a new genesis chain. Head persistence and later
+witness/transparency support remain follow-up work; neither is implied by a
+single signed checkpoint.