Dead RNode picker behind never-defined COLUMBA_BLE_ENABLED + latent CoreBluetooth restore-id footgun

[torlando-tech]

Summary

Two legacy RNode-configuration views are gated behind a compile flag, COLUMBA_BLE_ENABLED, that is never defined in any build configuration (no .pbxproj/.xcconfig SWIFT_ACTIVE_COMPILATION_CONDITIONS entry). They are therefore permanently dead code, and they carry a latent CoreBluetooth state-restoration footgun if anyone re-enables the flag.

Surfaced during the Model-B RNode-over-BLE hardening pass (sibling work to #101).

Dead code

• Sources/ColumbaApp/Views/Settings/BLEDevicePickerSheet.swift — entire file under #if COLUMBA_BLE_ENABLED
• Sources/ColumbaApp/Views/Settings/RNodeConfigSheet.swift — entire file under #if COLUMBA_BLE_ENABLED

The live RNode setup flow is the multi-step RNodeWizardView (RNodeWizard/*), which is what selectInterfaceType(.rnode) presents. The single-sheet RNodeConfigSheet + BLEDevicePickerSheet pair is unreferenced and only compiles under the never-defined flag. DiscoveredDevice was already extracted to Models/DiscoveredDevice.swift (ungated, shared with the wizard's DeviceDiscoveryStep), so the gated files no longer carry anything the live path needs.

Latent restore-identifier concern (the reason this isn't just "delete dead code")

The app process can run two CoreBluetooth centrals simultaneously on Model B:

• Mesh central — SwiftBLEBridge.centralRestoreIdentifier = "network.columba.ble.central"
• RNode BLETransport central — BLEConstants.RESTORE_IDENTIFIER_KEY = "com.columba.ble.central" (reticulum-swift)

Findings:

1. No collision today — the two restore identifiers are distinct (network.columba.ble.central vs com.columba.ble.central), so CoreBluetooth state restoration routes each central's preserved peripherals correctly. The earlier worry that the mesh and RNode centrals "share a restore id" does not hold against the current code.
2. But they are confusingly near-identical (network. vs com. prefix, same suffix). A future edit that copy-pastes one constant for a new central — e.g. re-enabling the picker and giving it its own scanning central — could silently reuse an identifier. Two CBCentralManager instances created with the same CBCentralManagerOptionRestoreIdentifierKey in one process is unsupported and mis-routes restored peripherals on background relaunch.
3. This becomes live only if ModelBRNodeService.rnodeBackgroundRestoreEnabled is flipped on (currently defaults false), at which point the RNode central participates in state restoration alongside the mesh central.

Suggested resolution

• Delete BLEDevicePickerSheet.swift and RNodeConfigSheet.swift (the wizard fully supersedes them), or wire COLUMBA_BLE_ENABLED into a real build config if the single-sheet flow is still wanted.
• Centralize the two CoreBluetooth restore identifiers (and give them visibly distinct, hard-to-confuse names) so a future central can't accidentally reuse one. Add a brief comment that each CBCentralManager in the process must carry a unique restore identifier.

Notes

Latent only — no user-visible bug today (flag undefined, background restore off by default). Filing per the same-day flagged-issue policy so the record doesn't live only in a memory note.