Bolt passkey method ignores discovered device kind when auth bit 0x01 is unset

## Summary

In the Bolt pairing flow, the passkey entry method shown to the user is chosen **only** from the discovery authentication byte:

```rust
// crates/openlogi-hid/src/pairing.rs — Notification::Passkey handler
let method = match pairing_auth {
Some(auth) if auth & 0x01 != 0 => PasskeyMethod::Keyboard(digits),
_ => PasskeyMethod::Pointer { clicks: passkey_to_clicks(value), passkey: digits },
};
```

If a keyboard-like device is discovered but its `pairing_auth` byte does not carry bit `0x01`, the session may still have been opened expecting keyboard entropy, yet the UI falls back to the pointer (click-sequence) method. The user is then shown click instructions for what is actually a keyboard passkey, the receiver keeps waiting for typed digits, and pairing times out.

Raised by Greptile on #381. This is **pre-existing behavior** — #381 (a refactor sweep) only tightened the passkey *digit* validation around this block; it did not introduce or change the method-selection condition, so fixing it there would be out of scope.

## Open question / needs hardware

Whether `pairing_auth & 0x01` is genuinely unreliable for keyboard-like Bolt devices, or whether the discovered `kind` should be consulted as a fallback, needs verification against real Bolt keyboards + receiver — the maintainer's hardware. If confirmed, the fix is to fold the discovered `kind` into the method decision (e.g. treat keyboard-like kinds as keyboard entry when the auth bit is ambiguous).

Start in crates/openlogi-hid/src/pairing.rs at the Notification::Passkey handler and trace how pairing_auth and the discovered kind are available during the Bolt pairing flow. Verify the behavior with real Bolt keyboards and a receiver, then confirm that the selected method matches the device and pairing no longer waits for the wrong input.

Written by the indexing model from the issue text.