Consult the open admission flags before the unusable-allowlist siren

[maxy-player]

Problem

At 54cf74b8334c64c5a1975bac698f68170c0e7301, crates/maxplayer-core/src/seller_node/run.rs:2252-2266:

    // surfaces, so the flags cannot rescue a list that matches nobody.
    if seller.accept_offers_only_from.is_empty()
        && (seller.accept_open_targeted || seller.claim_open_pool)
    {
        return None;
    }
    if !seller.accept_offers_only_from.is_empty() {
        return Some(format!(
            "seller node WARNING: this seat can claim NOTHING as configured — all {} entr(y/ies) in \
             [seller] accept_offers_only_from are unusable, and a populated allowlist fences out \
             everyone else on BOTH surfaces, so no offer can reach this seat at all. {}. Correct \
             the entries, or remove them. THREE ROUTES BACK IN: {}.",

The open flags are consulted only on the empty-list arm. A populated allowlist whose entries are all unusable falls through to the second arm, which never reads accept_open_targeted or claim_open_pool.

So with a populated-but-unusable allowlist and accept_open_targeted = true, the operator is told:

• "this seat can claim NOTHING as configured"
• "a populated allowlist fences out everyone else on BOTH surfaces"
• "no offer can reach this seat at all"
• "Correct the entries, or remove them"

All four are false. A targeted offer from an un-named buyer is admitted. The same holds for the pool surface when claim_open_pool = true.

The in-code comment at line 2251 states the stale premise directly — "the flags cannot rescue a list that matches nobody" — which has been false since #923 opened the targeted surface independently of the allowlist.

Why this matters, and what it costs if the analysis is wrong

This is an operator-facing warning that states a false absolute and then prescribes an action on it. Nothing on the wire is wrong and no funds are at risk; the cost is that an operator with a working open surface is told they have none, and is directed to edit config that is not the cause.

If this analysis is wrong, the cost of fixing it is a warning that stays silent in a case where it should fire. That direction is worth checking in review.

Both the string and the predicate encode the pre-#923 rule. Correcting the wording alone would leave the guard firing in the same wrong cases, so a text-only fix reads correct and is not.

Suggested shape: consult the open flags on the populated arm too — either suppress the siren when a surface is genuinely open, or keep it and name which surface still admits offers.

What remains unverified

• Read, not run. No test was executed against this path.
• The doc comment at crates/maxplayer-core/src/home.rs:373 uses the same "fences out everyone" framing. Whether it is wrong in the same way is not analysed here.
• No check of whether any test asserts the current wording.

Provenance

Found by worker-advertise-admission while building PR #942 and deliberately not fixed there — it predates that delivery, and the reviewing seat excluded it from that grade as a non-gating reasoned note. Filed after that disposition landed, not during it.