Harden SHM against retained zero-copy views (#272)

[cboulay]

Restacked: onto #274 / #268. The read-only SHM view now lives in #268's Channel._deliver_from_shm; the deferred-close commit applied unchanged.

Stacked on #274. Split from #273: the parts of the #272 fix that stand on their own. The ChannelFailed policy and the dead-segment race stay in draft #273.

Changes

• Tolerant SHM close (shm.py): if SharedMemory.close() raises BufferError because views into the segment are still alive (a unit kept a zero-copy array), SHMContext drops its handle to the mmap and closes the fd. The mapping is unmapped when the last view is collected, and the GraphServer still unlinks the segment when its leases end. Before this, the channel died for good when the publisher grew its SHM. Relies on SharedMemory's private _mmap/_fd; close() is unchanged from Python 3.8 through 3.14.
• Leak fix: SHMContext.wait_closed() also closes the segment. A monitor task cancelled before it first ran never executed its finally (the "Exception ignored in SharedMemory.__del__" noise at shutdown).
• Grow race fixed: on a grow the publisher closed the old segment at once. A message already sent names it, and a channel that hadn't processed that message still had to attach it; if the publisher held the last lease, the GraphServer unlinked it first and the channel died with FileNotFoundError. Two quick grows lost this race whenever timing shifted (it broke Surface a dead channel to subscribers; refuse attaching unlinked SHM (#272) #273's race test, and later the existing grow test under Elide coordinate axes a receiving channel already holds #276). The publisher now retires the old segment with the last msg_id sent under its name and closes it once the backpressure wait for msg_id L + num_buffers is over. By then every channel has released message L, and a channel attaches the segment a message names before it can release it.
• Read-only SHM messages: the channel caches shm[buf_idx].toreadonly(), matching the TCP path. Subscribers could previously write into memory shared with the publisher and every other subscriber.

Behaviour change

Editing a received array in place (msg.data *= 2) now fails with "assignment destination is read-only" on SHM deliveries, as it already did over TCP. Worth a release note for the beta.

Not fixed here

A message kept past its callback is still overwritten when the publisher reuses its slot. This PR only stops the crash; units that keep received data must copy it. The baseproc hash witness, which did this implicitly, is fixed in ezmsg-org/ezmsg-baseproc#18.

Tests

• test_shm.py::test_close_with_live_view
• test_shm_grow.py::test_cross_process_grow_with_retained_views: a receiver keeps every message across two grows. Without the fix it hangs.

Full suite against a private GraphServer: only the 10 test_settings_json_schema / test_inspect_command failures that also fail on the base branch. test_shm_resize_race_repro_completes passes, and the grow tests passed 8/8 under the timing that used to lose the race.

Cost: the read-only view is ~20 ns/msg; the tolerant close runs only when a segment is closed.