docs: propose LuceEngine component boundaries

[Graffioh]

Summary

• define LuceEngine::generate() as the single local request-generation entry point for HTTP and daemon callers
• move request lifecycle, scheduling, cancellation, retry, cache coordination, controls, and shutdown out of HttpServer
• replace the misleading ModelBackend versus SeqEngine peer structure with SingleRequestExecutor and BatchExecutor capabilities below LuceEngine
• keep sockets and API formatting in HttpServer, and keep model-family state and GGML objects below the execution boundary
• define owned requests, bounded generation output, typed completion, overload, progress, snapshot, and shutdown semantics

Design

HTTP or daemon adapter
  -> LuceEngine::generate()
       -> request coordination
            -> SingleRequestExecutor
            or BatchExecutor
                 -> model-family state
                 -> optional IPC
                 -> GGML
  <- token, progress, and terminal events
  -> protocol formatting
  -> client

There is one request-level function named generate(). The final target removes ModelBackend::generate(), restore_and_generate(), and the HTTP worker-versus-scheduler branch.

The two lower executor contracts remain different because they represent different units of model work. They are model capabilities below the shared request lifecycle, not alternate serving paths.

Boundaries

• HttpServer owns routes, JSON validation, chat rendering, tokenization, sockets, heartbeats, SSE, and response JSON.
• LuceEngine owns the backend lifetime, request queue, scheduling mode, generation policy, bounded output, typed controls, and shutdown.
• Model-family code owns weights, caches, graphs, device state, sampling mechanisms, snapshots, and GGML execution.
• BackendIpcProcess and role-specific IPC clients remain model implementation details.

These are ownership boundaries. The design does not rely on C++ public or private access to define them.

Relationship to active refactors

• PR #688 and its implementation follow-up own launch-time configuration. This RFC begins at BackendPlan -> create_backend() -> BackendRuntime; LuceEngine takes ownership of that runtime.
• PR #689 defines the API-facing terminal error mapping consumed by HTTP after generation completes.

BackendPlan stays launch-time only. ServerConfig does not enter backend construction or model-family code.

Scope

Documentation only:

• replace docs/specs/engine-components.md with the revised LuceEngine target
• update the README documentation link

The RFC includes a staged migration. The first implementation step is an owned GenerateRequest and a model-free bounded Generation channel test.

Verification

• traced complete-request and continuous-batch execution against upstream/main@298031aa
• checked the history and invariants introduced by PR #594
• reconciled the ownership model with the active BackendPlan and BackendRuntime refactor
• compared two structurally different target designs and checked the selected design for pass-through layers and state leakage
• verified current vLLM, SGLang, and llama.cpp primary architecture sources
• ran git diff --check and checked balanced Markdown fences

[Graffioh]

Superseded by draft implementation PR #692, which carries this RFC forward with the first owned-generation lifecycle slice.