fix: Apply restrictive permissions to shared memory

[whoisj]

What does the PR do?

Changes the permissions applied to the shared memory used by stub processes for communication purposes from the default 664 to 640 removing world read/write and restricting group to read-only.

Root Cause

The bi::shared_memory_object defaults to 664 permissions at creation when no permissions are specified.

Fix

Specify the desired permissions when creating the bi::shared_memory_object object.

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Changes shared memory access permissions at creation.

The PR appears safe to merge; no actionable issues were found.

What we checked:

• Stub keeps write access: The launcher starts the stub as a child with the same user identity. Owner read/write permissions remain enabled.
• Permissions survive growth and restart: Growth resizes the existing object. Restart uses the creation path that applies the explicit permissions.

Summary

Changes shared-memory creation to request owner read/write and group read-only permissions (0640).

• Passes explicit permissions to bi::shared_memory_object.
• Keeps owner access needed by the Python stub.
• Preserves the restriction during growth and reapplies it on restart.
• No actionable issues found. No build or runtime tests were run.

_{Reviews (1) · Last reviewed commit: "fix: Apply restrictive permissions to sh..." · Reviewed by Greptile}