Mic: let record() from the release callback wait briefly for the request lock

[ainyan03]

Summary

Mic.record() called from the buffer release callback returned false even though the queue had room and no begin()/end() was in progress, so the "two buffers alternately, re-queued from the callback" pattern described in the header stopped capturing after the first buffers.

The publisher notifies the capture task while it still holds the request lock. With a DMA backlog the task fills and releases the buffer before the publisher unlocks, the callback's record() finds the lock taken, and the in-task path returned false at once.

Reported in detail at ainyan03#1 (ESP32-S3 + ES7210, arduino-esp32 3.3.9).

Changes

• Mic_Class.inl (_rec_raw()): from the capture task, a taken request lock is waited for a tick at a time instead of failing immediately. The wait ends with false when
  • _task_running has been cleared (an end() or sample-rate rebuild holds the lock while waiting for the task to exit; both clear the flag first), or
  • a few ticks have passed (in_task_lock_wait_ticks): the plain atomic has no priority inheritance, so a middle-priority task could otherwise keep the holder off the CPU indefinitely and the callback would never return.
    Both slots already taken is decided before touching the lock: only the capture task frees a slot, so waiting from its own callback cannot change that.
• The notify stays under the lock on purpose: issuing it after the unlock would let an end() delete the task between the unlock and the notify.
• Mic_Class.hpp: the release-callback note and record()'s @return now list every reason the callback's record() returns false (queue full, stop in progress, lock held too long, different rate), and the "never block in it" note states the exception.

Public signatures are unchanged. Callers outside the capture task are unaffected.

Behavior note: from the release callback, record() may now block for up to a few ticks while another task finishes publishing a request. Previously it never blocked there (and failed instead).

Verification

Test firmware re-queues each released buffer from the callback and counts record() failures, using the reporter's reproduction (600 ms of DMA backlog before the first two record() calls):

Build	ESP32-S3 (ES7210)	ESP32 (Core2, PDM mic)
develop	first 2 callbacks fail, capture stops	not measured
this PR	200 callbacks × 5 runs, 0 failures (2 buffers and 1 buffer)	200 callbacks × 5 runs, 0 failures

Also checked on both: end() called while the callback keeps re-queueing returns within 20 ms and the task exits; a sample-rate change from another task while the callback re-queues a single buffer completes (the callback's record() at the rebuild instant returns false once, as documented) and capture continues at the new rate.

Two rounds of independent adversarial review. The first found that an unbounded per-tick wait could hang the capture task under priority inversion (a middle-priority task starving the lock holder), which led to the bounded wait. CI run on the ainyan03 fork before this PR.