feat(swarm): signature service — Ed25519 sign/verify over JCS (#77)

[Dewinator]

Summary

• New mcp-server/src/services/signature.ts implements the reusable Ed25519 sign/verify primitives for Swarm Phase 2 (issue Swarm Phase 2: src/services/signature.ts — Ed25519 sign/verify with JSON canonical form #77).
• Pure RFC 8785 (JCS) canonicalizer + node:crypto Ed25519 wrappers; no external dependencies.
• 22 new tests pin the wire-format contract from docs/SWARM_SPEC.md §2.

Research summary

• mcp-server/src/services/ is the canonical home for new services (matches node-identity.ts from Swarm Phase 1b: scripts/init-node-identity.mjs + node_identity_get MCP tool #76); tests live under src/__tests__/ and run via node --test on the compiled output.
• The existing crypto.ts exposes a non-JCS canonicalJson and Ed25519 helpers used by the legacy genome-lineage code. SWARM_SPEC §2 explicitly mandates JCS (RFC 8785), so reusing the legacy helper would silently drift the wire-format. New file added; legacy file untouched.
• Node's crypto.sign(null, data, key) is the correct Ed25519 path (Node 14+); createSign('sha256') does NOT work for Ed25519 because Ed25519 prehashes internally.
• For JCS conformance we used pure JSON.stringify-based string/number serialization: V8's JSON.stringify follows the same minimal-escape rules and the same ECMAScript Number-to-String algorithm RFC 8785 §3.2.2 references. Object key sorting uses Array.prototype.sort (default UTF-16 code-unit order, exactly what RFC 8785 §3.2.3 requires).
• Issue Swarm Phase 1b: scripts/init-node-identity.mjs + node_identity_get MCP tool #76's node-identity.ts pattern was followed for testability — no I/O coupling in the pure functions; signWithSelfKey accepts a loadPem injection point so tests don't touch disk.

What this does NOT do

• No networking, HTTP, or libp2p wiring (issue Hard constraint).
• No integration into existing record-creation paths (lesson synthesizer, hub anchors, advertisements). That is the explicitly-deferred Phase 2.5 follow-up.
• No migration files touched, no node-identity script touched (read-only dependency on the privkey at ~/.mycelium/node.key).
• No key rotation, no revocation lists, no multi-signature schemes (v2 scope).

Constitution affirmation

• Touches Pillar 6 — Cyber security: every record that ever leaves a node will be signed via these primitives. JCS bytes-stability + Ed25519 verification are what make the swarm trust premise work — no agent can speak for another node, signatures are computed over canonical bytes (not the producer's serialization), and the verifier collapses every malformed-input path to false rather than throwing on the network edge.
• Adjacent Pillar 1 — Decentralized, networked AI and Pillar 5 — Experts in the swarm rely on signatures to attribute records to a node_id; this PR enables those without yet asserting them.
• No pillar is weakened. The privkey continues to live only in the chmod-0600 file written by scripts/init-node-identity.mjs; this service reads it through an injectable loadPem hook so tests never need a real key on disk.

Test plan

cd mcp-server && npm test

Expect 22 new passing tests under signature (canonicalize conformance, sign/verify round-trip, tamper detection, wrong-key rejection, signature-field exclusion, signWithSelfKey wrapper). The pre-existing migration-070-node-identity.test.js failure is unrelated — it fails because supabase/migrations/070_node_identity.sql is still pending in PR #79.

Spot-check the wire-format anchor test (sign: wire-format anchor — independent re-derivation matches): it builds the canonical bytes by hand ({"a":1,"m":2,"z":3}) and signs via raw node:crypto, then asserts equality with the service's output. If this ever fails, the service has drifted from the JCS contract.

🤖 Generated with Claude Code