fix(q): restrict outbound q-wire builtins under IPC

[belowzeroff]

How it looks from the user's side

A restricted native IPC client connects to a rayforce-q server started with -U pw and asks the server to open an outbound q-wire connection:

(.q.connect "127.0.0.1" 45701 "" "" 500)

Before -- the restricted client could force the server to connect out to the q target:

client handle=0
client error: 0
fake target output: accepted

After -- the same restricted IPC request is denied before any outbound q-wire connection is opened:

client handle=0
client error: 0
fake target output: not accepted

The client-side error formatting in this repro is coarse, so the target-side accept is the key observable: before the fix the fake q target accepts a connection; after the fix it does not.

What changed

Registers the outbound q-wire builtins as restricted:

• .q.connect
• .q.send
• .q.close

These now use RAY_FN_RESTRICTED instead of RAY_FN_NONE, matching the native IPC networking verbs such as .ipc.open, .ipc.send, and .ipc.close.

With rayforce -U, the core evaluator already blocks functions marked RAY_FN_RESTRICTED, so restricted IPC clients can no longer use .q.connect to make the server initiate outbound q-wire connections. Local and unrestricted callers keep the same behavior.

Tests

git diff --check origin/master...fix/q-restrict-ipc-builtins
make test RAYFORCE_LOCAL_PATH=/Users/evgenbyelozorov/Documents/work/rayforce-q/test/tmp/rayforce-c
make rayforce RAYFORCE_LOCAL_PATH=/Users/evgenbyelozorov/Documents/work/rayforce-q/test/tmp/rayforce-c
python3 /private/tmp/rayforce_q_repro50.py ./rayforce

Targeted repro was run against both origin/master and this branch to confirm the before/after accept behavior.