Remove equipment protocol survey — driver list confirmed by v2 team

The OtOpcUa v2 implementation team committed all 8 core drivers from
internal knowledge of the estate, making the formal protocol survey
unnecessary for driver scoping. Removed current-state/equipment-protocol-
survey.md and cleaned up all references across 7 files.

The UNS hierarchy snapshot (per-site equipment-instance walk for site/area/
line/equipment assignments + UUIDs) is now a standalone Year 1 deliverable,
decoupled from protocol discovery. Tracked in status.md and goal-state.md
UNS naming hierarchy section.

Eliminates ~52 TBDs (all placeholder data in the pre-seeded survey rows).

STATUS.md

@@ -22,7 +22,7 @@ The plan is substantively fleshed out. All three core documents are populated, t
 **Component detail files:**
 
 - [`current-state/legacy-integrations.md`](current-state/legacy-integrations.md) — authoritative inventory for pillar 3 retirement. **Closed as denominator = 3**: LEG-001 Delmia DNC, LEG-002 Camstar MES, LEG-003 custom email notification service. Historian MSSQL reporting surface explicitly carved out as *not* legacy.
-- [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md) — template/schema for the Year 1 protocol survey that drives OtOpcUa core driver library scope. **Dual mandate:** same discovery walk also produces the initial UNS naming hierarchy snapshot (equipment-instance granularity) for the `schemas` repo. Six expected categories pre-seeded as placeholders.
+- ~~`current-state/equipment-protocol-survey.md`~~ — **Removed.** Protocol survey no longer needed; the OtOpcUa v2 implementation team committed the 8-driver core library from internal knowledge. The UNS hierarchy snapshot (equipment-instance walk) is now a standalone Year 1 deliverable tracked separately.
 - [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) — meeting-prep artifact for the (now completed) digital twin management conversation; "Outcome" section at top captures the resolution.
 
 **Input / reference files:**
@@ -65,7 +65,7 @@ All four items from the previous status check have been **advanced to the point
 ### External-dependency items — waiting on real-world action
 
 1. **BOBJ → Power BI coordination with reporting team.** Plan position documented in `goal-state.md` → Strategic Considerations → **Enterprise reporting: BOBJ → Power BI migration (adjacent initiative)** — three consumption paths analyzed, recommended position stated (Path C with Path A as strategic direction), eight questions and a four-bucket decision rubric included. **Action needed:** schedule the coordination conversation with the reporting team; bring back a bucket assignment. Once a bucket is assigned, update `goal-state.md` → Enterprise reporting and, if the outcome is Bucket A or B, update `roadmap.md` → Snowflake dbt Transform Layer to include reporting-shaped views.
-2. **Equipment protocol survey execution (dual mandate: protocol survey + initial UNS hierarchy snapshot).** Template, schema, classification rule, rollup views, and discovery approach documented in [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md). The file is pre-seeded with expected categories (OPC UA-native, Siemens S7, Allen-Bradley EtherNet/IP, Modbus, Fanuc FOCAS, long-tail) as placeholders — these are **not authoritative** until real discovery data replaces them. **Dual mandate:** the same discovery walk also produces the initial **UNS naming hierarchy snapshot** (equipment-instance granularity, with site/area/line assignments and stable UUIDs) that gets committed to the `schemas` repo — see `current-state/equipment-protocol-survey.md` → **Companion deliverable** and `goal-state.md` → **Unified Namespace (UNS) posture → UNS naming hierarchy standard**. Two outputs, one walk. **Action needed:** assign a survey owner; walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates (steps 1–3 of the discovery approach) within Q1 of Year 1 — capturing both equipment-class data (for the protocol survey) and equipment-instance data (for the UNS hierarchy) in the same pass; interview-driven gap-filling follows in parallel with core driver build. This is a **Year 1 prerequisite** — the OtOpcUa core driver library cannot be scoped without it, and the canonical model v1 cannot be published without the initial hierarchy snapshot. **Sub-blocker:** the UNS hierarchy's enterprise-level shortname is currently a placeholder (`ent` in goal-state.md); the real shortname needs to be assigned before the initial hierarchy snapshot can be committed to the `schemas` repo. Small decision, blocking the hierarchy materialization.
+2. **UNS hierarchy snapshot walk.** The protocol survey has been **removed** — the OtOpcUa v2 implementation team committed the core driver list (8 drivers) based on internal knowledge, making a formal protocol survey unnecessary for driver scoping. What remains is the **UNS hierarchy snapshot**: a per-site equipment-instance walk capturing site / area / line / equipment assignments and stable UUIDs, which feeds the initial `schemas` repo hierarchy definition and canonical model. See `goal-state.md` → **Unified Namespace (UNS) posture → UNS naming hierarchy standard**. **Action needed:** assign a walk owner; walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates across integrated sites within Q1–Q2 of Year 1; capture equipment instances at site/area/line/equipment granularity (not protocol — that's already resolved). The canonical model v1 cannot be published without the initial hierarchy snapshot. **Sub-blocker:** the UNS hierarchy's enterprise-level shortname is currently a placeholder (`ent` in goal-state.md); the real shortname needs to be assigned before the initial hierarchy snapshot can be committed to the `schemas` repo.
 3. **Digital twin use case 2 — funded simulation initiative (exploratory).** The digital twin management conversation is complete; management provided three use cases and the plan absorbs two of them (canonical state vocabulary + canonical model declaration — see closed items). **Use case 2 (Virtual Testing / Simulation)** is served minimally by Redpanda historical replay + OtOpcUa's architectural support for a future `simulated` namespace, but **full commissioning-grade simulation stays out of scope** for this plan. **No action needed** unless and until a funded simulation initiative materializes with a sponsor, scope, and timeline; at that point the meeting-prep brief at [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) can be reused for a use-case-2-specific scoping conversation. Keep on the radar, don't actively work on it.
 
 ### Closed since last status check