agent: fix NoInputNoOutput agents rejecting all pairing requests

[abezukor]

Problem

It is currently impossible to register a working NoInputNoOutput agent, because the capability string passed to RegisterAgent is derived automatically from which handler fields are set:

• All handlers None → capability is NoInputNoOutput, but BlueZ still calls RequestAuthorization for incoming just-works pairing (and AuthorizeService for service connections). Since the handler is None, bluer replies with org.bluez.Error.Rejected — so every pairing attempt fails.
• Setting request_authorization to accept → the derivation flips the capability to DisplayYesNo, so MITM-capable centrals (iOS in particular sets the MITM flag) negotiate numeric comparison instead of just-works. The phone then shows a "confirm this code" dialog for a code that a headless device cannot display anywhere.

This also contradicts the existing Agent documentation, which states:

Setting all handlers to [None] (the default) will result in a NoInputNoOutput handler that accepts all requests.

The all-None agent rejected all requests instead, so the documented behavior never worked.

Use case

A headless device (no display, no input) exposing a GATT service with encrypt-read/encrypt-write characteristics. Phones must be able to pair via just-works with a single consent tap and no passkey dialog. This requires advertising NoInputNoOutput and accepting RequestAuthorization/AuthorizeService.

Fix

1. Exclude request_authorization and authorize_service from the capability derivation. Per the BlueZ agent API, RequestAuthorization is called "to request the user to authorize an incoming pairing attempt which would in other circumstances trigger the just-works model" — it is a local authorization policy decision, invoked regardless of the published capability, not an input/output capability. The same applies to AuthorizeService. Only request_confirmation now implies yes/no capability. With this change, an agent with only authorization handlers correctly advertises NoInputNoOutput.

2. Make the all-None default match the documented behavior. When no handlers are set, default RequestAuthorization and AuthorizeService handlers that accept all requests are installed at registration, so the default Agent is the documented "NoInputNoOutput handler that accepts all requests". Code-input requests (RequestPinCode, RequestPasskey, etc.) still reject — BlueZ does not send them to a NoInputNoOutput agent.

Behavior changes

• An agent with only request_authorization/authorize_service set now publishes NoInputNoOutput instead of DisplayYesNo. Such configurations were effectively broken before, since they had no request_confirmation to satisfy numeric comparison.
• An all-None agent now accepts incoming just-works pairing instead of rejecting it, matching the existing documentation.

cargo build and cargo clippy --all-features pass with no new warnings.

🤖 Generated with Claude Code - I (a Human) did manually verify the issue and audit the code.