Unpaired client answers pairing_required instead of unauthorized when the activation also names an invalid pairing method #207

Summary

When a server sends an unpaired client a server/activate that is broken in two ways at once, sendspin-cpp closes the connection with client/goodbye reason pairing_required. The spec says the reason should be unauthorized.

pairing_required tells the user "turn on unpaired access and this will work". In this case it won't: with unpaired access on, the same activation is still rejected, this time with pair/abort method_not_supported. So the user is pointed at a setting that doesn't fix anything.

Steps to reproduce

1. Start a sendspin-cpp-cli player with unpaired access off, which is the default. Do not pass --allow-unpaired.
2. Run the conformance client validator with the unpaired suite and fault injection enabled:

   uvx --from git+https://github.com/Sendspin/conformance sendspin-validate --suite unpaired --fault-injection

3. When the validator asks how your app connects, pick server-initiated, then pick the player from the list it found.
4. Follow the prompts until step U4. Leave unpaired access off when it asks.

At U4, the validator connects without pairing, so the handshake uses the Sentinel PSK. It then sends:

{
  "type": "server/activate",
  "payload": {
    "activities": ["playback", "pairing"],
    "active_roles": [],
    "pairing": {"method": "pairing_psk"}
  }
}

Expected: client/goodbye with reason unauthorized.
Actual: client/goodbye with reason pairing_required. The validator reports finding UNPAIRED-004 as FAIL.

Why unauthorized is correct

That activation has two separate problems:

1. It asks for playback on an unpaired connection while unpaired access is off. The activity set is not allowed (messaging.md, the "Allowed activity sets" table and its footnote).
2. It asks for pairing_psk pairing on a Sentinel connection. pairing_psk is only valid when the handshake matched the pairing PSK (messaging.md, the paragraph after the table). That is true whatever the unpaired-access setting.

The client picks its rejection by the first rule that applies (messaging.md, server/activate, "admissible"):

• pairing_required applies only if turning on unpaired access would make the activation admissible. Here it would not: problem 2 remains. This rule does not apply.
• unauthorized applies if the activity set is not allowed for the matched PSK. This rule applies, because of problem 1.

Cause

inadmissible_reject_reason() in src/admission.h decides between the two reasons using relies_on_unpaired_access(). That function asks whether admissible(..., unpaired_access=true) would pass. But admissible() only checks the activity set and the active roles. It never looks at the pairing method.

The pairing-method check lives later in ConnectionManager::on_server_activate() (src/connection_manager.cpp), in the category_ok / offered / format block. It only runs after an activation has passed admissible(). So when admissible() fails, the method is never considered, and "would enabling unpaired access fix it?" wrongly answers yes.

Suggested fix

Answer pairing_required only when enabling unpaired access would make the whole activation acceptable, including its pairing method:

1. Pull the existing pairing-method check out of on_server_activate() into a small helper. The check is: the method is present; pairing_psk if and only if the PSK category is PAIRING; the method is offered; for dynamic_pairing_code, the format is offered. For example, bool pairing_method_acceptable(conn, msg), which returns true when pairing is not in activities.
2. In the rejection path, choose PAIRING_REQUIRED only when inadmissible_reject_reason() says so and pairing_method_acceptable() holds. Otherwise close with UNAUTHORIZED.
3. Keep using the same helper in the existing method-check block, so the two paths can't drift apart.

Add a unit test next to the existing admission tests:

• an unpaired (Sentinel) session;
• unpaired access off;
• activities: ["playback", "pairing"], pairing.method: "pairing_psk";
• expected result: UNAUTHORIZED.

The existing case should still give PAIRING_REQUIRED: activities: ["playback"] with active_roles: ["player@v1"], which is the spec's worked example.

Notes

• Only a misbehaving server would send this activation, so it is an edge case. It is still the exact situation the rule order exists to make deterministic.
• Found with the conformance client validator (feat(validator): add the unpaired, pairing_psk and post-pairing suites conformance#164, step U4). Tested against sendspin-cpp-cli main @ 7501898, built on sendspin-cpp.