feat: EventLoopProvider + WorkerLoop interface for driver integration

[FumingPower3925]

Summary

Define the engine-level interfaces that allow database/cache drivers to share the HTTP server's event loop. This is the foundational abstraction that enables per-worker affinity for driver connections.

Design

New interfaces in the engine/ package:

type EventLoopProvider interface {
    NumWorkers() int
    WorkerLoop(n int) WorkerLoop
}

type WorkerLoop interface {
    RegisterConn(fd int, onRecv func(data []byte), onClose func()) error
    UnregisterConn(fd int) error
    Write(fd int, data []byte)
    CPUID() int
}

Key Decisions

• Separate from HTTP connection tracking: driver FDs are stored in a new driverConns map on each worker, distinct from HTTP connections
• Callback-based: onRecv is called by the event loop when data arrives on the FD, keeping the protocol-agnostic design
• CPUID(): exposes the CPU the worker is pinned to, enabling NUMA-aware allocation in drivers
• Atomic guard: per-iteration check for driver registrations is gated behind an atomic.Bool so there is zero overhead when no drivers are registered

Acceptance Criteria

• EventLoopProvider and WorkerLoop interfaces defined in engine/
• Documentation comments explain the contract (thread-safety, callback semantics)
• No implementation yet — just the interface definitions and types
• Existing engine code compiles without changes

Labels

engine, driver, priority/critical-path