fix(protocol): pace CoAP request sends

[Jason-Morcos]

Summary

• pace the first Block2 GET request and every later block
• pace ordinary POST requests and OBSERVE registrations
• recheck session liveness after pacing and before a request send
• keep automatic ACKs, ping(), and teardown deregistration immediate

Why

The session already spaces Block2 continuations and Block1 uploads, but the first GET, an ordinary POST, and subscribe() could still be sent back-to-back with earlier traffic.

The hardware report in #53 found the missing case: about eleven OBSERVE registrations were sent immediately after the DTLS handshake. The session stayed healthy for roughly five seconds, then the dryer stopped answering for nearly three minutes. Pacing subscribe() inside the session protects every caller from that burst instead of relying on each caller to remember it.

The Home Assistant integration I use with a locally connected Samsung washer and dryer already calls pace() before initial and refresh subscriptions. A regression here covers that pattern and confirms the session-owned call does not add a second wait once the interval has already elapsed.

Fixes #53.

Stack / merge order

1. fix(protocol): pace CoAP request sends #51 (this PR) is directly on current main and should merge first.
2. feat(protocol): validate GET and POST request options #48 adds validated query and extension options.
3. feat(protocol): add CoAP DELETE requests #49 adds DELETE.
4. feat(protocol): add bounded Block1 POST uploads #50 adds bounded Block1 POST uploads.

Validation

• 274 SmartThings-Local tests on current dependencies and the Python 3.11 dependency floor
• 1,625 LocalThings tests against this exact source tree
• deterministic eleven-registration pacing, caller-side pacing compatibility, liveness cleanup, immediate-response token ordering, and unpaced control-send regressions
• wheel and sdist content checks plus isolated install/import smoke tests
• bytecode compilation and share-safety checks

[Jason-Morcos]

@QuiteYellow I rebased this one off main so it doesn't have to be gated as part of the stack (and instead gated the rest of the stack on this one).

[QuiteYellow]

Merged. Hardware-validated on a dryer and an oven first.

The recreate was the test I cared about. A container recreate is what wedged my oven on 7 August, and it is the same shape as #37:

07:33:34  dryer  DTLS connected — subscribing 11 paths
07:33:38  dryer  seeded → 25 links; sensors live
07:33:35  oven   DTLS connected — subscribing 11 paths
07:33:40  oven   seeded → 16 links; sensors live

Both connected, seeded and stayed up, then three clean 60s poll-windows each: 0 err, 0 ping-fail, 0 timeouts, steady-state rates matching the pre-merge baseline.

Connect to seeded went from about 2s to about 4s on the dryer. That is the eleven registrations now spaced at the rate-limit interval, which is the whole point.

The sweep cost is smaller than I predicted, and I had the reason wrong. I read "25 links" as 25 requests and expected the sweep to go from 834ms to about 5s. It does not: poll_scheduler logs len(indexed) after a single blockwise GET of /device/0, so the tree is one transfer and your change adds one pace interval at its head rather than one per link. Measured: dryer 834ms to 1260ms, oven 2665ms to 2690ms.

This closes #53. The registration burst there is the genuine per-request case, and test_every_subscribe_in_registration_burst_honors_rate_limit walks exactly it.

One thing I am leaving for a separate change: mqtt_demo still sleeps 50ms between subscribes at bridge.py:389. pace() absorbs that rather than adding to it, which is what test_existing_caller_pacing_before_subscribe_does_not_wait_twice protects, so it is redundant but harmless.

Not proven by this run: a refrigerator. #37 stays open until the reporter there confirms on a release.