P2: Fix Go-adapter parity gap — gate driver/chain scheduling on actual implementation

[FumingPower3925]

Part of #151.

Problem. featureSetFor (cmd/runner/main.go:467) grants Drivers=true + Middleware=true to every Go adapter, so the scheduler runs 12 chain + 4 driver cells against Go servers that 501/404. Flags are derived from the engine name string + category, not from what the binary serves. Rust/Python/Bun get false so they're skipped — so today's DB/middleware 'comparison' is celeris-vs-nothing.

Goal. Capability flags reflect reality; no scenario scheduled against a server that 501s.

Scope.

• After P2: Implement DB-driver endpoints across adapters (real PG/Redis/memcached calls) #157/P2: Implement middleware-chain endpoints across adapters (/chain/*) #158 land, set Drivers/Middleware per adapter based on actual endpoint support (a manifest or a startup capability probe — hit /__caps or parse a declared list).
• Guard: a 501/404 on a scheduled scenario is a hard error (fail the cell), not a silently-recorded zero — so future parity drift is caught.

Acceptance. Every scheduled (server×scenario) pair is implemented; a deliberately-unimplemented endpoint fails the run loudly.

Refs: cmd/runner/main.go:467-501, interleave/schedule.go:42, servers/servers.go.