v3.2.0

feat(records)!: signed DHT record API — v3.2.0

Adds the missing piece for service discovery: typed, signed, content-addressed records stored in the relay mesh DHT. Closes the gap that previously forced consumers to poll HTTP topology endpoints or parse V1 macula-relay heartbeat misnomers.

macula_record:

  build/4 — construct + sign with Ed25519 over deterministic CBOR of [type, payload, pubkey, ttl_ms]

  key_of/1 — 32-byte BLAKE3 of (canonical_body || sig). Including the signature in the hash means two distinct signers of identical content produce distinct addresses — every record uniquely keyed by (signer, content)

  verify/1 — Ed25519 signature check

  canonical_body/1 — exposed for external verifiers

macula SDK surface:

  put_record/2, find_record/2, find_records_by_type/2 — RPC over _dht.put_record / _dht.find_record / _dht.find_records_by_type procedures (5s timeout)

  subscribe_records/3, unsubscribe_records/2 — pubsub on _dht.records.<type>.stored. Pid callbacks receive {record, Record}; fun callbacks invoked directly

Type tags are application-defined 0..255 bytes; SDK does not interpret payloads. Convention: 0x02 = station_record (hecate), 0x11 = content_announcement.

Backend requirements: relay must advertise the three _dht.* procedures and publish on _dht.records.<type>.stored topics. V1 macula-relay does not implement these. Forward-looking SDK surface; first consumer is hecate-station.

Tests: 13 record helpers (build/sign/verify/key_of) + 13 SDK API tests (meck-mocked relay) — all green. Dialyzer clean for new modules (pre-existing warnings in macula_dist_discovery untouched).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>