docs: document the grid-column coupling and its failure mode

docs/cable-sizing-module.md

@@ -54,6 +54,28 @@ No changes to `circuit-project-command.model.ts`, `project-command.service.ts`,
 any Zod command schema, any migration for `circuits`/`project_revisions`, or
 any existing test.
 
+## Coupling to the grid UI (the one fragile point)
+
+Everything described above - the calculation, the audit table, applying a
+result via `circuit.update` - depends only on stable, explicitly documented
+domain fields (`cableType`/`cableCrossSection`/`cableLength`/
+`circuitTotalPower`/`voltage`/`protectionDevice.ratedCurrentA`), the same
+ones `AGENTS.md` already treats as protected ("Protection and cable data
+belong to the circuit"). None of that breaks if the grid UI changes.
+
+The one place that *is* coupled to a UI implementation detail: the click
+trigger in `circuit-tree-editor.tsx` matches grid **column keys**
+(`cableSummary` and `cableCrossSection`, defined in
+`circuit-grid-model.ts`) to decide where to show the calculator icon.
+Column visibility and order in this app are a per-browser user preference,
+not fixed - so this is checked against both known cable-related columns to
+reduce (not eliminate) the chance a user's personal column layout hides the
+trigger entirely. If a future column rename removes both keys, the failure
+mode is purely cosmetic: the calculator icon/click stops appearing on that
+cell, nothing crashes, no data is affected, and the rest of the app
+(including manual cable-field editing) is completely unaffected - the
+module's actual logic and persistence never depend on this column key.
+
 ## How a suggestion is applied
 
 The module never writes to `circuits` directly. The modal's "Empfehlung