refactor: split executor/engine.rs and eliminate ExecutionContext clone per request

[maralbahari]

Summary

ExecutionContext owns long-lived shared state: DB connection pool, HTTP client, and server config. Cloning it per request means each clone holds independent references to those resources, making it easy for future fields to silently diverge between the shared instance and the per-request copy. This refactor removes client_auth (the only per-request field) from ExecutionContext, making the struct purely shared and immutable for the server lifetime.

• client_auth: Option<String> removed from ExecutionContext. Supplied per-request via ExecuteRequest::with_auth() instead, threaded as a parameter through run_blocking and run_stream.
• ExecuteRequest builder added: ExecuteRequest::new(payload, exec_ctx).with_auth(token).run().await. The boundary between shared config and per-request state is now explicit in the type.
• resolve_exec_ctx in agebtic-server/handlers/common.rs deleted. Replaced by extract_bearer(headers, config_key) and a direct ExecuteRequest construction, zero clones per request. extract_bearer returns the request-level bearer token if present, and falls back to openai_api_key from `AppState
• execute() kept as a one-liner shim over ExecuteRequest so existing call sites compile without changes.
• engine.rs split into four focused modules: inference.rs (HTTP transport), rehydrate.rs (history rehydration), persist.rs (response persistence), engine.rs (orchestration only). All public names re-exported from executor/mod.rs, no import paths changed.

Test Plan

• cargo clippy --all-targets -- -D warnings clean
• cargo test -- --test-threads=$(nproc): 201 tests pass, 0 failed

[ashwing]

run_blocking and run_stream are private which is fine — rehydrate_conversation, call_inference, and persist_response are pub so Praxis filters can still compose steps individually. One thing worth thinking about before tool dispatch lands: ExecuteRequest::run() is currently a straight pipeline. Tool calls need to re-enter inference after execution, so run() will eventually need to loop or accept some kind of decision callback. Might be worth leaving that door open in the shape of ExecuteRequest now rather than having to reshape a stable API later.

[maralbahari]

run_blocking and run_stream are private which is fine — rehydrate_conversation, call_inference, and persist_response are pub so Praxis filters can still compose steps individually. One thing worth thinking about before tool dispatch lands: ExecuteRequest::run() is currently a straight pipeline. Tool calls need to re-enter inference after execution, so run() will eventually need to loop or accept some kind of decision callback. Might be worth leaving that door open in the shape of ExecuteRequest now rather than having to reshape a stable API later.

@ashwing Thank you for the feedback. I think we should modify APIs as needed when the feature actually lands. Right now we have no tool calls, so any shape we add to ExecuteRequest would be based on guesses about how tool dispatch will work in practice. Those guesses will almost certainly be wrong once we see the real requirements.
Adding a callback or loop shape today means future implementors have to work around our speculation rather than design from real constraints. The "open door" would end up being dead weight or worse, the wrong door entirely.
When tool execution is actually implemented, reshaping run() is cheap. ExecuteRequest is not a public stable API with many external callers. We can make any structural changes the real implementation needs at that point.

[ashwing]

Makes sense — no point adding shape we'll likely have to undo. Will revisit when tool dispatch is real.

[maralbahari]

@franciscojavierarceo @leseb ready for review.