ADR-0017: document trunk traffic semantics + ASCII topology

While reviewing the single-switch design Viktor asked whether both the
home LAN and the camera VLAN 'go via pfSense which forwards upstream' -
a natural misreading a future reader would repeat. Added a section
spelling out the vmbr0 fork: untagged home LAN is L2-bridged past
pfSense (gateway stays the AX6000, rack outage does not affect it, OOB
via 4G survives), while tagged-30 can only land on the dCCTV interface,
making a pfSense bypass impossible by construction. Includes a compact
ASCII topology for terminal readers alongside the SVG.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md

@@ -35,6 +35,52 @@ may reach ISAPI/RTSP directly; home-LAN clients route in via an AX6000 static
 route (10.0.30.0/24 via 192.168.1.2). 10.0.30.0/24 is deliberately NOT in the
 10.0.20.0/22 trusted source-IP allowlist.
 
+## Traffic on the trunk — how one cable carries two networks
+
+The LAN1 cable is shared, but the two networks on it diverge at `vmbr0`
+(the vlan-aware bridge on the PVE host), and only ONE of them ever touches
+pfSense:
+
+- **Untagged (VLAN 1, home LAN)** is plain L2 bridging: vmbr0 switches it
+  between the trunk, the host's own IP (192.168.1.127) and pfSense `net0` —
+  where pfSense sits as an ordinary LAN *client* (WAN 192.168.1.2). The home
+  LAN's gateway is and remains the AX6000; home-LAN traffic never transits
+  pfSense. Consequently a pfSense (or R730 VM-level) outage does not affect
+  the home LAN, and the apartment ↔ 4G-router ↔ UPS paths don't even leave
+  the switch (P1/P2/P3 bridge internally), so out-of-band recovery via the
+  4G router survives the whole rack being down.
+- **Tagged 30 (CCTV)** has exactly one possible landing: vmbr0 delivers
+  VID 30 only to pfSense `net3` (dCCTV, 10.0.30.1), which is the camera
+  segment's gateway, firewall and sole exit. "Camera → AX6000 → internet"
+  is impossible by construction, not merely by firewall rule.
+- pfSense forwards *upstream* only its own segments (10.0.10/20/30), NATed
+  out of its WAN toward the AX6000. Load-wise the trunk gained only the
+  camera's ~8 Mbps — it already carried all rack-bound home-LAN traffic.
+
+```text
+ INTERNET ── AX6000 192.168.1.1 (home GW; camera-day route 10.0.30.0/24 → .2)
+                │
+                │ apartment uplink · V1 untagged
+ ┌──────────────┴───────────────────────────────┐    ┌────────────────────┐
+ │ TL-SG105PE (mgmt 192.168.1.6)                │    │ vermont-garage     │
+ │ P1 apartment · P2 4G .7 · P3 UPS  [VLAN 1]   │◄───┤ HiLook, pure IR    │
+ │ P4 camera PoE [VLAN 30]                      │cat6│ 10.0.30.70 (Kea)   │
+ │ P5 TRUNK: V1 untagged + V30 tagged           │    └────────────────────┘
+ └──────────────┬───────────────────────────────┘
+                │ ONE cable (existing LAN1 run)
+ ┌──────────────┴───────────────────────────────────────────────┐
+ │ R730 · eno1 → vmbr0 (vlan-aware)                              │
+ │   ├─ untagged → host .127 + pfSense net0 WAN 192.168.1.2      │
+ │   └─ tag 30  → pfSense net3 dCCTV 10.0.30.1/24 (camera GW)    │
+ │ eno2 → vmbr2: dormant fallback leg                            │
+ │ vmbr1: tag 10 → dManagementsVms · tag 20 → dKubernetes (k8s,  │
+ │        Frigate on node1, go2rtc LB 10.0.20.204 → HA live)     │
+ └───────────────────────────────────────────────────────────────┘
+
+ Frigate 10.0.20.x ─RTSP :554─► camera · ha-sofia .8 ─:80+:554─► camera
+ camera ─NTP :123─► 10.0.30.1 · camera → anything else = DENY
+```
+
 ## Considered options
 
 - **802.1Q over the LAN path behind an UNMANAGED switch** (the original plan