docs: two verified ways to factory-reset a ring, plus an oura factory-reset subcommand

[nsandoval]

Both reset paths were blank spots in the repo: 0x1a was listed in the Horizon cheatsheet as "packet shape added as danger; not run", and no hardware path was recorded at all. Both are now verified on a Ring 4 (ORE_06, firmware 2.12.3).

Path A — the 0x1a command

Exposed as oura factory-reset --yes, which refuses to run without the flag.

The request bytes are built in the CLI rather than in oura-protocol, so firmware linking that crate has no way to emit a destructive command.

One correction to the existing notes: tools/oura_protocol.py:358 parses a tag 0x1B reply carrying a u16 status, but no reply arrives in practice — the ring resets and drops the link before answering. The reset still takes effect.

Path B — hardware, no BLE, no button

Flipping the Gen3/Ring 4 dock 180° four times with the ring seated on it, guided by the LED colour (blue → red → magenta → yellow), resets a ring that will not connect to anything.

This one matters beyond convenience. Every BLE reset path needs a device that is already bonded and authenticated, so a ring whose last bonded host is gone would otherwise be unrecoverable. The button-hold procedure in Oura's docs only exists on the separate Charging Case; this works on the plain dock.

Verified on a ring that would no longer connect through the Oura app, and on which the widely-repeated "tap the dock" trick did nothing — as expected, since that reboots the ring rather than erasing it.

The trap worth reading

The two paths differ in what happens to the boot-relative event counter. After the hardware reset it restarts near zero, so a sync cursor persisted from before sits millions of ticks ahead of any timestamp the ring can now produce — and drain_events returns nothing, forever, with no error. Reset sync_state.next_cursor to 0 after either path.

Also documented

• what a reset erases, including the anthropometric profile returning to firmware defaults (28 4B 02 B0)
• the dock's LED colours — notably that blinking blue means "not paired with the Oura app", which is the permanent steady state for a ring driven by this project, not a fault
• that consumer reset instructions end with "set up a new ring in the Oura App", which installs Oura's key and locks this project out
• bond ordering: a reset ring accepts new bonds from anything, but once provisioned it terminates the link of a central that is neither bonded nor able to start encryption, after two or three connection events with HCI reason 0x15. Pair every host that will need access while the ring is still freshly reset.