fix(shm): make rings work safely across app and coreaudiod users

## Context
For HAL virtual input/output, shared memory crosses process and user boundaries. The app or daemon may run as the logged-in user, while the HAL plug-in runs inside CoreAudio/DriverHelper/coreaudiod context.

A downstream app-owned producer may need the HAL driver to read a POSIX shm object created outside the HAL process. MARS currently creates rings in `mars-hal::shm_backend` with mode `0o600`.

## Risk
Unit tests that open the ring twice in the same process/user will pass, but real HAL usage can fail if the creator and reader are different users or sandbox contexts.

## Acceptance criteria
- Validate real permissions needed for macOS HAL plug-in access from coreaudiod/DriverHelper.
- Update ring creation/opening to use the minimum permissions that work cross-user.
- Document the security model: namespace ownership, app ids/uids, cleanup, and who can read/write a ring.
- Add an integration or manual acceptance test that proves a user-space producer and HAL consumer can access the same ring.
- Avoid fallback modes that silently report success while the HAL device cannot read the ring.

Start in mars-hal::shm_backend and inspect how POSIX shared-memory rings are created and opened. First validate the permissions required when a macOS HAL plug-in runs under coreaudiod or DriverHelper, then define the namespace, ownership, cleanup, and reader/writer model. Done means the minimum working permissions are implemented, documented, and demonstrated by an integration or manual test using a user-space producer and HAL consumer.

Written by the indexing model from the issue text.