Release 0.5.0: detector parity, and terminal login

[Zenofex]

Two things, one of which changes output for existing consumers.

bootintel login. Browser-approved terminal sign-in, RFC 8628 shape. Replaces pasting BOOTINTEL_API_KEY by hand, which the README had to teach read -s to do safely.

The real reason it exists: the server gates x-api-key at Pro, because "API access" there means CI and scripting. Applying that to interactive terminal use would have put the applicability lookup, the only path usable on a client device under an NDA, out of reach of the entry paid tier. The bic_ token resolves ahead of that gate server-side, so programmatic access stays Pro while a terminal login starts at Researcher.

0.5.0, not 0.4.3. The detector parity work already on main changes output labels, which the policy at the top of CHANGELOG.md calls MAJOR; pre-1.0 that moves the minor. Anything parsing .findings[] by label should look before upgrading. Notably OpenSBI moves from Bootloader to Runtime firmware, and previously lost to U-Boot in the precedence chain, so on a RISC-V log its version never reached output at all.

Verified against the running server, not just in tests. The flow printed the link and code, polled, was approved from a browser session, and collected a bic_ token, which then returned 67 applicability findings with log_received: false. Probe accounts and all test authorizations were removed from the database afterwards.

Two things that live run changed:

• It survived a connection reset mid-poll, proving the retry worked, but printed a warning that was the only thing about a successful login that looked wrong. Transient retries are now quiet, bounded at 20, and visible under -v.
• clippy correctly rejected a runtime assertion on a constant, so the poll-interval floor is a const assertion and the test exercises the real computation rather than a tautology.

299 tests pass, clippy clean under -D warnings, rustfmt clean, cargo deny check all ok.