ci: probe whether GitHub runners can execute io_uring

[beinan]

What

Adds an informational CI job that answers one question with data: can GitHub-hosted runners actually execute io_uring?

No production code touched. The job is continue-on-error and never gates a merge.

Why

#273 measured a thread-per-core io_uring (monoio) data plane winning on all three of latency, per-core throughput, and memory (+35% throughput, −19% p50, −26% p99, −34% RSS vs full Tokio; 8.05× scaling at 8 rings). Before that migration lands, the test strategy depends entirely on whether CI can run io_uring:

• If supported — the new data plane can be exercised directly in CI, same as the existing fuse mount e2e job runs a real kernel mount.
• If not — it must be feature-gated, with CI compiling but not executing it, and correctness verified on self-hosted or production hardware.

That is a fork in the road for the migration PR, so it is worth resolving first rather than guessing.

Kernel version, the io_uring_disabled sysctl, and seccomp filtering are three independent gates — a container can satisfy the first two and still block the syscall — so this probes actual runtime behaviour instead of inferring it.

What it checks

1. A monoio::RuntimeBuilder::<IoUringDriver> runtime builds (catches panics, since monoio panics rather than erroring when a blocking pool is missing).
2. A SO_REUSEPORT listener binds and completes a real TCP roundtrip — this is the exact mechanism thread-per-core scaling depends on, not just "the syscall exists".
3. bind_to_cpu_set works (CPU pinning, the other half of thread-per-core).

Plus the environment surface: kernel, arch, nproc, io_uring_disabled, seccomp mode, container detection. All of it lands in the job summary.

Isolation

The probe crate has its own manifest with an empty [workspace] stanza, so it is excluded from cargo build --workspace and pulls monoio into no normal build. Verified locally:

members: [talon-core, talon-coordinator, talon-transport, talon-worker,
          talon-backend, talon-fuse, talon-client, talon-observability]

.github/probe/target/ is gitignored. The workflow only triggers on workflow_dispatch or PRs touching the probe itself, talon-transport, or talon-worker.

Local result

On this dev host (kernel 6.6.141, io_uring_disabled=0, no seccomp):

URING_BUILD=ok
REUSEPORT_BIND=ok 127.0.0.1:42011
ROUNDTRIP=probe
CPU_PIN=ok
PROBE_RESULT=SUPPORTED

The point of this PR is to learn whether the same holds on ubuntu-latest.

Verification

• cargo build --workspace --all-targets --all-features --locked — unaffected
• cargo fmt --all --check — clean
• Probe runs green locally via the committed manifest

Refs #273

🤖 Generated with Claude Code