Forwarding sync reconciles against daemon-reported live rules

[FAZuH]

Parent

#24 — Spec: One typed seam through which all NAT state flows

What to build

The natmap daemon reports its live NAT rules read-only through a new GET /rules endpoint, and the forwarding sync reconciles against them. The endpoint returns structured live-rule models (kind, ext_ip, int_ip, ports, proto) parsed from the daemon's own rule listing, attributed by rule comment, including multiport (--dports) rules. The typed client gains a rules() read. The forwarding sync fetches the reported rules, diffs its desired set against them, and deletes stale forwarding rules with their real attributes via the typed client. find_stale_rules and parse_dnat_rule are deleted from auto-discover. The sync's error handling is fixed: failed rule deletions are no longer silently swallowed, and a failed create no longer skips the hairpin install. Stale multiport forwarding rules are now cleaned up.

Acceptance criteria

• GET /rules returns structured live rules (kind, ext_ip, int_ip, ports, proto) parsed from the daemon's rule listing, including multiport and comment attribution, distinct from GET /mappings
• The typed client exposes a rules() read over the same seam
• Forwarding sync fetches reported rules and deletes stale groups with their real attributes; find_stale_rules/parse_dnat_rule are deleted from auto-discover
• A stale multiport forwarding rule is detected and removed (regression case that currently fails)
• Forwarding sync no longer swallows delete errors, and a failed create no longer skips the hairpin
• GET /rules parsing is unit-tested in the natmap crate (single-port, multiport, hairpin, port-mapping); forwarding reconcile is unit-tested against an in-memory natmap adapter
• Full workspace builds and all existing unit tests pass

Blocked by

• Typed natmap client with honest vocabulary #25 — Typed natmap client with honest vocabulary

[FAZuH]

Whole-repo architecture audit (2026-09-30) added a finding for this spec.

DRY inside apply_forwarding_group. Delete-before-create is expressed by constructing the identical config twice, about 30 lines apart. DnatConfig is built at crates/auto-discover/src/forwarding.rs:222 and again at :246, byte-identical; HairpinConfig at :287 and :309, likewise. Hoisting each into one let removes four struct literals and keeps one spelling of each shape, so a future field addition cannot be made in one copy and forgotten in the other.

Two related cuts from the same file, from the over-engineering pass:

• crates/auto-discover/src/config.rs:91 and :103 declare RProxyLocalConfig and RProxyRemoteConfig, which differ only in the struct name. Both are already used (config.rs:69,72), so this is duplicated knowledge, not a speculative type. One type, wired to both serde keys, no wire change. Tracked in Cut dead code and unused dependencies #40.
• ResolvedPortType::RProxyLocal::proxy_on, RProxyRemote::proxy_on and ForwardRemote::proxy_on (config.rs:156,162,172) are assigned in resolve_all and never read by any match on port_type. Only ResolvedService::proxy_on is bound, at consul.rs:264. Tracked in Cut dead code and unused dependencies #40.

The test-side cost of this path is #46: ten sync_service_* tests and the apply_forwarding_group proptests. Note that forwarding.rs:642 hairpin_or_ed and :659 preserve_src_ip_or_ed re-implement the production OR-aggregation inside the test body, so they are Ugly Mirror tests subsumed by the four boolean-table tests at :701,716,727,738. forwarding.rs:604 all_ports_in_group hand-rolls a key comparison that service_matches_group at :570 already exists to do, 30 lines above it. All three are in #46.