HerdOS RFID Hardware Bridge

Assessment before this update
- The platform already had RFID list sheets, duplicate-read highlighting, manual tag entry, serial-reader capture, keyboard-wedge capture, unknown-tag handling, and offline queueing.
- The missing layer was a clear hardware pairing surface for real devices and a documented line between browser-supported pairing and certified vendor SDK adapters.
- The API seed readers were demo profiles. They are now explicitly marked as demo-profile records and not as certified live hardware connections.

What is wired now
- Main platform and HerdOS Field include a Hardware pairing bridge inside the RFID station.
- The bridge shows browser capability status for Bluetooth, Serial/USB, HID, USB permission, and keyboard-wedge capture.
- The bridge includes buttons for Pair Bluetooth, Pair Serial / USB, Pair HID, Check USB, Retry active reader, and Disconnect.
- Keyboard-wedge RFID readers are captured through the existing scanned-text listener and saved into the active RFID list.
- Serial/COM readers can stream line-based tag payloads through Web Serial where the browser and operating system permit it.
- HID readers can request browser permission through WebHID and attempt to parse input reports into tag payloads.
- USB permission can be checked through WebUSB, but live reads still require the reader to expose serial/HID/keyboard mode or a vendor middleware/SDK adapter.
- Bluetooth pairing can request a reader through Web Bluetooth, but live BLE reads require the reader to expose known GATT services or operate in keyboard/middleware mode.
- Scan events are shown in a recent scan log and routed into the same offline RFID collection sheet used by manual and existing reader flows.

Operational behavior
- Duplicate tags are not added twice. Existing rows are highlighted and the read count increases.
- Unknown RFID values are retained for later herd registry matching.
- Scans save locally first so the main and field apps remain usable offline.
- Field app scans keep the field device identity, department, site, and farm organization context.
- Main and field reader profiles remain tenant-scoped so one farm's readers do not leak into another farm.

Vendor adapter status
- Allflex and Datamars/Tru-Test are strong first hardware targets because official materials show livestock EID reader workflows, Bluetooth connectivity, USB/serial workflows, and keyboard-wedge style capture on some devices.
- Corral or other reader vendors should be added after confirming official SDK, export format, or supported middleware.
- Do not claim formal vendor certification until that exact reader, firmware, operating system, browser/native wrapper, and workflow has been tested and documented.

Practical deployment guidance
- For immediate pilots, prefer reader modes that output scanned tags as keyboard text, serial lines, CSV exports, or vendor middleware JSON/CSV.
- For native iOS/Android production builds, add dedicated Bluetooth/BLE and USB/serial libraries inside the mobile app rather than relying only on browser APIs.
- For Windows/macOS chute stations, Chrome or Edge on HTTPS/localhost gives the best Web Serial/WebHID coverage.
- Keep manual tag entry available everywhere because reader batteries, antennas, OS permissions, and browser support can fail in the field.

Remaining production work
1. Select exact first reader models and firmware versions.
2. Test all supported connection modes: keyboard wedge, serial/USB, HID, Bluetooth, CSV export, and vendor middleware.
3. Add vendor-specific adapter modules only after official SDK or protocol confirmation.
4. Record low-battery, disconnect, duplicate-read, weak-network, and offline-reopen behavior during pilot sessions.
5. Keep a hardware certification matrix before making public compatibility claims.
