Answer a BluMint close of a key the bridge holds nothing under with 200

[oconnorjoseph]

BluMint treats a close answered 404 as a failed close and hands the match to a host. Its contract says that when a partner holds nothing under a close's idempotencyKey, it records the key closed and answers 200, so a later creation under that key is refused. The bridge answered 404 { "code": "unknown_match" } for that case, and again on every repeat.

What changes

• A close for a key the bridge holds nothing under, for that connection, still marks the key closed, and now answers 200 { "closed": true }, the same as a close of a match that is already over. A repeat answers the same.
• Every other close is unchanged: a live match closes, an ended match answers 200, and a later creation under a closed key answers 409 key_reused.
• Since a close no longer needs to know whether a key only had refused creations, blumint_refused_keys and the code that kept it are removed, and migration 026 drops the table.

Tests

tests/blumint.rs: a_closed_match_sends_nothing and a_close_naming_another_connections_key_ends_nothing now expect 200 { "closed": true } where they expected 404 unknown_match. Against nightly's code both fail with left: (404, {"code": "unknown_match"}), right: (200, {"closed": true}). With the fix, cargo fmt --check, cargo clippy --locked --workspace --all-targets -- -D warnings and cargo test --locked (300 tests) pass.

Docs

• docs/guides/BLUMINT_QUICKSTART.md: the close section says a key that made no match stays closed for a day after its close, and that a close of a key the bridge holds nothing under answers as a match that already ended does. The 404 unknown_match row is gone from the close table, and the 200 row now covers a key with no match, whether its creations were refused or none arrived.
• docs/guides/INTEGRATIONS.md: the close bullet says such a key answers 200 and is closed all the same.