Adopt the dedicated RS485 lock board as the only hardware adapter

The locker client already contains a dedicated rs485_lock_board driver and adapter for the proprietary hexadecimal RS485 protocol with XOR/BCC validation, DIP addresses, unlock commands, and query-all status reads.

However, both production adapters currently implement the Waveshare-shaped LockerBusPort:

• actuation is named flashRelay
• a Waveshare-specific pulse duration is passed to every adapter
• actuation returns Promise<void>
• door feedback is exposed only through a later readDoorSensors call

The dedicated board already returns a feedback status (00 or 11) approximately 500 ms after an unlock command. The current codec validates this byte but deliberately discards it, so the application cannot use the board's direct feedback.

ADR-0061 explicitly preserves this behavior and must be superseded as part of the change.

• Replace flashRelay with a protocol-neutral compartment unlock operation.
• Return an optional post-actuation state observation from the hardware port.
• Map the dedicated board's unlock response through the configured feedback polarity:
  • door_closing: 00 = open, 11 = closed
  • door_opening: 11 = open, 00 = closed
• Use that response as the first post-actuation state observation.
• Keep command acknowledgement and physical opened/door_jammed events separate.
• Keep query-all polling for manual changes, uncommanded openings, and continued state observation.
• Keep open, closed, and unknown as the application-facing state model.
• Preserve actuation when the input already reports open, as required by #302.
• Remove the Waveshare adapter, native flash-register implementation, relay-specific startup failsafe, and modbus-serial dependency when no longer used.
• Remove Waveshare-only relay terminology from ports, tracing, logging, health reporting, tests, and documentation.
• Keep command deduplication because the board protocol has no transaction identifier.

The production board uses fixed serial settings:

• 9600 baud
• 8 data bits
• no parity
• 1 stop bit
• no flow control

These values should live inside the dedicated adapter rather than remain operator-configurable.

The external hardware configuration should normally contain only the serial device path, preferably a stable /dev/serial/by-id/... path. Response timeout and reconnect policy should use documented internal defaults unless field experience demonstrates a need for operator configuration.

Also:

• remove flashDurationMs
• migrate the external modbus: configuration to a minimal RS485/serial configuration
• map backend slaveId directly to the physical DIP address (1..31)
• retain zero-based configured compartment addresses and translate them to one-based wire channels inside the adapter
• remove backend adapter selection after existing installations have a safe migration path
• coordinate backend and locker-client rollout so persisted runtime profiles and config hashes remain valid

• Continue validating XOR/BCC over every complete frame.
• Allow more than 500 ms for the delayed unlock response.
• Preserve serial transaction ordering and command priority.
• After timeout, malformed BCC, or excess input, discard buffered and late bytes before the next transaction.
• Do not infer query-all response length from a declared channel count. Decode the complete received frame and select only configured channels.
• Missing status bits must produce unknown, not an incorrect state or process failure.
• Treat DIP addresses 1..31 as the supported range despite contradictory vendor text mentioning 1..99.
• Continue using query-all polling; unsolicited 0x82 feedback requires customized firmware and is not part of the standard board.
• Define timeout behavior for the case where the lock may have actuated but the response was lost.
• Verify recovery after USB-RS485 disconnect and reconnect without restarting the process.
• Keep full-open and multi-channel unlock commands out of the product interface unless a separate safety-reviewed use case requires them.

Create one validated reference build based on:

• Raspberry Pi
• USB-to-RS485 adapter
• dedicated 8-channel RS485 lock-controller board
• compatible 12 V electric locks with the selected feedback type
• correctly sized 12 V power supply
• Raspberry Pi DC-DC converter
• XH2.54 lock/feedback cables
• RS485 and power wiring

Before simplifying the BOM, verify:

• whether the documented 6 A limit is total board current
• lock inrush current and safe simultaneous actuation limits
• flyback, short-circuit, overcurrent, reverse-polarity, ESD, and surge protection provided by the board
• whether the feedback contact represents the physical door position or only the latch/bolt state
• feedback polarity and contact bounce on the selected reference lock
• RS485 termination, biasing, grounding, and reliable multi-board daisy-chain wiring
• whether DIP-address changes require a power cycle
• how the physical full-open button is protected against accidental or unauthorized use

Remove the following from the minimal BOM only after validation:

• Waveshare Modbus RTU Relay (D)
• custom Open-Locker connection board
• connection-board terminal sets
• intermediate relay-board wiring
• external flyback components if the dedicated board is proven to provide adequate protection

Document the required XH2.54 harnesses explicitly; the product package includes only one lock cable.

The vendor's maximum of 31 boards does not guarantee that all boards can be queried every 500 ms at 9600 baud.

• Measure a complete polling cycle with the expected production board count.
• Define a supported maximum at the current polling interval, or distribute board queries across cycles.
• Ensure unlock commands retain priority over background polling.
• Run a sustained polling and actuation soak test on the production Raspberry Pi.
• Test at least two DIP-addressed boards on one physical RS485 bus before claiming multi-board production support.

• Create a new ADR that supersedes the applicable parts of ADR-0061 and the Waveshare hardware decision in ADR-0004.
• Review the startup, polling, reconnect, and direct-addressing ADRs for references that need superseding or clarification.
• Update the locker-client README and hardware integration documentation.
• Update English and German Bills of Materials.
• Update website hardware, architecture, and operations documentation.
• Document commissioning: stable serial path, DIP address, channel mapping, feedback type, and physical verification.