io_uring: fixed-file support is unimplemented behind a malformed accept SQE — readiness checklist before it can be enabled

[FumingPower3925]

Fixed files are disabled at runtime on every kernel I have tested, and the reason is our SQE, not
the kernel.

prepMultishotAcceptDirect (engine/iouring/sqe.go) builds on prepMultishotAccept, which sets
accept_flags = SOCK_NONBLOCK|SOCK_CLOEXEC, and then writes IORING_FILE_INDEX_ALLOC into
file_index. The kernel's io_accept_prep rejects a fixed file slot combined with SOCK_CLOEXEC
with -EINVAL — a direct descriptor lives in the ring's file table, not the process fd table, so
close-on-exec is meaningless for it.

So the probe fails, and every run logs:

INFO fixed files runtime probe failed, disabling
  reason="ACCEPT_DIRECT rejected by kernel: cqe.res=-22 (likely -EINVAL=-22)"
INFO io_uring engine selected tier=high ... fixed_files=false

-22 is EINVAL. The comment at probe.go:333 attributes this to the kernel — "the kernel
registered files but refuses ACCEPT_DIRECT (seen on 6.6.10-cix aarch64). Treat as unsupported." —
but it reproduces on 7.0.12-linuxkit aarch64 too, and it is our flag combination.

Measured

Dropping SOCK_CLOEXEC from the direct variant only:

prepAccept(sqePtr, listenFD, uint32(unix.SOCK_NONBLOCK))

flips the probe immediately:

INFO io_uring engine selected tier=high multishot_accept=true multishot_recv=true
  provided_buffers=true fixed_files=true send_zc=true
INFO io_uring engine listening ... fixed_files=true ... kernel=7.0.12-linuxkit

No other change. Same kernel, same container, same run.

Why I am not shipping the one-line fix yet

Because it would turn on a code path that has, as far as I can tell, never executed. Fixed files
have been silently off everywhere, so everything gated on cs.fixedFile is effectively unexercised
— and celeris#538 is already an example of what is waiting there: two async unix.Write(cs.fd, ...)
sites with no !cs.fixedFile guard, where cs.fd is a table index rather than a descriptor, so the
bytes would go to whatever real fd holds that number.

Sequencing this the other way round would take a dormant defect and activate it. #538 (and a sweep
of every other cs.fixedFile branch) should land first, then this, then a full validation pass —
the performance win is real but it is not worth enabling an untested path immediately before a
release.

Found by a multi-agent audit of the io_uring SQE builders; confirmed experimentally against main
at 0a1ceff.

[FumingPower3925]

Swept every cs.fixedFile branch before touching this. Do not merge the one-line fix.

I ran a four-surface audit of the fixed-file code paths — raw syscalls, SQE flag selection, the
accept/close slot lifecycle, and handoff to other subsystems — each finding then attacked by an
independent reviewer instructed to refute it. Eleven distinct defects survived. None were
refuted.

The conclusion is not "one line and a validation pass". Fixed-file support is substantially
unimplemented, and the malformed accept SQE has been hiding that by keeping the whole feature off.

Blockers — the default receive path is broken

1. prepareRecv's single-shot branch omits IOSQE_FIXED_FILE (worker.go:3494-3498).
   prepRecv (sqe.go:37-45) writes only sqe[0], sqe[4], sqe[16], sqe[24] — it never
   touches the flags byte, and no prepRecvFixed exists. GetSQE zeroes the SQE
   (ring.go:276), so the flag is provably absent, not merely inherited.

   This is the default configuration: w.bufRing is only built when
   CELERIS_IOURING_MULTISHOT_RECV=1 (worker.go:508), so every connection takes the else branch
   and arms a recv against a raw fd number that equals its slot index. Low slots hit fds 0/1/2 and
   fail with -ENOTSOCK; higher slots in the 65536-entry table collide with real sockets in the
   process — another worker's listen fd, a driver.go database connection — and the ring reads
   their bytes.

   That the send path next door branches correctly (prepSendZCFixed/prepSendZC,
   prepSendFixed/prepSendPlain, and if cs.fixedFile { setSQEFixedFile(sqe) } on WRITEV) shows
   this is an omission, not a decision.

2. flushSendLink's linked RECV omits the flag while its paired SEND sets it —
   worker.go:3857-3864, two lines apart, the cs.fixedFile branch immediately above. Also
   reachable only when bufRing == nil, i.e. the same default.

3. prepareRecv's multishot branch keys off w.fixedFiles, not cs.fixedFile
   (worker.go:3495) while every send uses the per-conn flag. After the runtime fallback at
   worker.go:1194-1197 flips the worker flag off, connections accepted earlier still have
   cs.fixedFile == true and lose the flag on re-arm.

4. prepCloseDirect builds an SQE the kernel rejects, and closes the wrong slot (sqe.go:79-88):

   sqe[1] = sqeFixedFile | sqeCQESkipSuccess
   // file_index at offset 44 (0-based index + 1 for direct)
   *(*uint32)(unsafe.Pointer(&sqe[44])) = uint32(fileIndex)

   The comment states the +1 requirement and the code does not do it — off by one, so it closes
   the neighbouring slot. Separately, IORING_OP_CLOSE must not carry IOSQE_FIXED_FILE; the
   direct form is selected by file_index alone.

Structural: w.conns has two conflicting index namespaces

5. w.conns is indexed by real fd for driver connections and adopted (transplanted) fds, and by
   slot index for fixed-file connections. onAcceptedFD (worker.go:1273) writes
   w.conns[slot] with no occupancy check, so an accept can clobber a transplanted connection;
   driver.go:110-118 and :245-256 compare a real fd against the slot-keyed table and tear down
   live driver connections on a false collision.

6. Enabling fixed files permanently disables the io_uring→epoll drain and ctx.Hijack() — both
   refuse a fixed-file conn by design (transplant_source.go:72, :148; worker.go:1313,
   :1624). Correct as guards, but it means turning this on silently removes two features.

Behavioural regressions on the fixed-file path

7. No socket options are ever applied to a fixed-file connection (worker.go:1251-1257).
8. RemoteAddr is empty on every fixed-file connection (worker.go:1267-1271).
9. The fixed-file close path drops shutdown(SHUT_WR), the recv-buffer drain and forceRSTClose.
10. The slot is released back to the table before the queued CLOSE_DIRECT for it runs.
11. The table is never grown, and exhaustion is indistinguishable from any other accept error.

What I am doing

Nothing, deliberately. Fixed files stay off, which is where they already are. The accidental
-EINVAL has been acting as a safety interlock, and removing it without the above would take a
dormant feature and turn it into data corruption on the default configuration.

I would rather this issue became the readiness checklist for fixed-file support than a one-line
patch. Worth deciding separately whether to keep the code and finish it, or remove it and stop
paying the branch-maintenance cost on a path nothing exercises.

For the record, the sweep also verified a good deal as correct: every raw syscall on cs.fd
(surface 1 came back clean after #542), cancelConnOps and the WS pause cancel being user_data-keyed
rather than fd-keyed, prepSendSQE's four-way branch, the WRITEV flag, hijackConn's double guard,
and GetSQE's zeroing making flag inheritance impossible.