Name the two modules after their software: nftables and distribution

A module's identity is the software it is (ADR 0040). Two were named after the
job instead, and the job already had a name.

firewall installs the nftables package and runs nftables.service. The seat it
claims is the-packet-filter, which is correctly named for the role. Calling the
module firewall named neither the software nor the provision, and promised that
any firewall could sit there — the false genericity the naming rule forbids.

registry runs Distribution, the OCI reference implementation, and provides
artifact-store. So registry was a third name for a thing that already had two,
which is how one word ended up meaning the module, the software and the concept
in the same paragraph.

The capability stays firewall, and correctly: a capability IS a functionality, so
a node having one and fail2ban requiring one are both right. Only the module
moves.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx

modules/nftables/client.ts

@@ -0,0 +1,21 @@
+// The firewall's own code, in the module (novox/hq ADR 0039). The mesh computes this node's whole
+// rule set from every module's `listens` and writes it to /etc/nftables.conf (novox/hq ADR 0045);
+// the module loads it (the nftables service, reloaded whenever the rules change). This code exists
+// only to read back what is actually enforced — the enforcement itself is declarative.
+
+import { execFile } from "node:child_process";
+import { promisify } from "node:util";
+
+const run = promisify(execFile);
+
+export class FirewallClient {
+  static fromEnv(_env: NodeJS.ProcessEnv = process.env): FirewallClient {
+    return new FirewallClient();
+  }
+
+  /** The mesh's live table — exactly what is dropping and accepting on this node right now. */
+  async ruleset(): Promise<string> {
+    const { stdout } = await run("nft", ["list", "table", "inet", "mesh"]);
+    return stdout;
+  }
+}