feat(protocol): add shared MID exchange registry

[atc722]

Context

Thank you for clarifying the ownership and landing sequence in #56.

This is the standalone shared MID-registry slice agreed there. Both #36 and
#54 need to correlate tokenless CoAP control messages with pending requests.
Landing that lifecycle once avoids carrying separate read-side and write-side
MID registries before those PRs are rebased.

What changes

• Adds one private MID-indexed exchange registry shared by GET and POST while
  preserving the existing token-indexed response dispatch.
• Atomically registers both indices before sending and avoids reusing a MID
  that is still owned by a live exchange.
• Treats only an exact RFC 7252 four-byte v1 empty ACK or RST as a
  MID-correlated control message.
• Marks an empty ACK as acknowledged without completing the request; GET stops
  retransmitting that MID and waits for the token-correlated separate response
  under the existing overall deadline.
• Stores acknowledgement state on the exchange rather than in the response
  container, so clearing a stale Block2 response cannot discard the ACK state.
• Completes a matching bare RST with SessionError.
• Unregisters both token and MID indices after success, send failure, timeout,
  or RST.
• Drains both indices and wakes affected waiters with SessionClosedError from
  both close() and reader-thread teardown.
• Publishes the closed session state before draining, preventing a request that
  already passed its entry check from registering after the drain.

Scope

This PR intentionally does not include:

• feat(protocol): discover advertised OCF secure ports #36 discovery APIs or its remaining Block2 reassembly policy changes;
• fix(protocol): retransmit and fail fast on the write path #54 POST retry count, backoff, same-MID retransmission, or pacing policy;
• authentication, endpoint selection, ownership transfer, or public API
  changes; or
• MID registration for fire-and-forget ping and Observe traffic.

The existing Block2 duplicate, SZX, ETag, and accumulation semantics remain
unchanged. Moving acknowledgement state outside the response container also
addresses #36 review point 2 without bringing the rest of that PR into this
change.

Validation

• python -m pytest -q: 320 passed in a clean Python 3.13 environment
• focused MID lifecycle, reader-death, pacing, and stale-Block2 tests passed
• git diff --check
• share-safety check
• targeted Ruff check
• wheel and sdist build
• distribution-content verification
• isolated wheel and sdist imports

After this lands, I will rebase #36 and address its remaining review points,
then let @mbillow know that #54 is ready to rebase.

Refs #56

[QuiteYellow]

Approving and merging this.

It matches what #56 asked for in step 1. One structure serving both paths, allocated and indexed under the same lock before the send, and drained from close() and the reader finally through a single function. Leaving ping and Observe unregistered is the right call, since ping() never waits on a reply.

Two details I checked closely and both are right. ev.clear() sits inside the same locked block as the container read, so a response arriving between the check and the wait cannot be dropped. And publishing conn = None before the drain, with the second _check_live() after registration in post() and _exchange_block, closes the register-after-drain race properly.

Moving acknowledged onto the exchange also settles #36 review point 2, so that one is off your list before the rebase.

Three things I am taking on myself in a follow-up:

1. _exchange_block allocates a fresh MID per attempt, so an unacknowledged retry still goes out as a new request. @mbillow flagged this in the body of #54 and it predates your work. This PR hands same-MID retransmission to #54, which covers the write path, leaving the read half unassigned.
2. A matching RST, a token already in flight, and MID exhaustion all surface as a bare SessionError(). #23 added the typed hierarchy for exactly this.
3. _next_available_mid_locked walks all 65,536 MIDs before giving up.

I will land those on top before calling the rebases. Thanks for turning this around so quickly.