Make the interrupt poll thread persistent: park on detach instead of exiting

[Nursedude]

Deeper follow-up to #10 (the minimal one-line leak fix) — this eliminates the leak class rather than the instance. Maintainers' choice: merge #10 alone, or this instead (it supersedes #10); both fix meshtastic/firmware#10468.

Why go further than #10

Creating and destroying a pthread per attach/detach cycle is churn embedded targets shouldn't pay: consumers that detach/re-attach around every radio interrupt (meshtastic firmware does) spawn ~9–12 threads per minute — a fresh 8 MB stack mmap + clone3 each time even once #10 makes them reclaimable. On 32-bit router-class platforms (OpenWrt mips/arm, ~2 GB usable VA) the stranded variant exhausts address space in hours, and vm.max_map_count (65530 default) is its own ceiling.

Design

• The poll thread is created once per pinedio_init() (on first attach) and parks on a condition variable when the last interrupt detaches; the next attach signals it awake. Attach/detach cycles toggle a flag — zero thread churn.
• There is never a mid-life thread to join, so detaching from within the interrupt callback (which runs on this very thread) is safe by construction — the self-join hazard the af9bc27 guard worked around no longer exists.
• The thread terminates exactly once, in pinedio_deinit() (join; pthread_detach(self) in the pathological deinit-from-callback case).
• Lock order is uniform (usb_access_mutex → poll_park_mutex); the poll thread never holds the park mutex while taking the USB mutex.

Deliberate behavior change: a pinedio_get_input() failure now latches in_error and keeps polling at the normal cadence — self-healing when a later read succeeds — instead of silently killing the poll thread until the next full deinit/init (the old failure mode left interrupt delivery dead with no recovery path). If you prefer the old semantics I can park on error instead.

Testing status

Compile-tested against the full meshtastic firmware native build (2.7.24/472b14c, aarch64). Not yet soak-tested on hardware — my three CH341 field units are currently validating #10 (numbers posted there: leak eliminated). I'll run this branch through the same live-hardware soak on request, or once there's maintainer appetite for the deeper change.