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/tools/index.ts

@@ -0,0 +1,19 @@
+// firewall's tools — one, and the useful one: what is actually enforced. The rules are the mesh's,
+// computed from every module's listens; this reads the live table so a declared scope can be checked
+// against what the packet filter is really doing.
+
+import { registerModuleTools, type ToolDefinition } from "@novox/mesh-sdk/tools";
+import { FirewallClient } from "../client.js";
+
+export function getFirewallTools(firewall: FirewallClient): ToolDefinition[] {
+  return [
+    {
+      name: "firewall_rules",
+      description: "The mesh's live nftables rules on this node — what is actually accepting and dropping.",
+      input: {},
+      run: async () => ({ ruleset: await firewall.ruleset() }),
+    },
+  ];
+}
+
+registerModuleTools("firewall", () => getFirewallTools(FirewallClient.fromEnv()));