Function code_mode_tools_from_executor 

pub fn code_mode_tools_from_executor(
    builder: ServerBuilder,
    config: &ServerConfig,
    executor: Arc<dyn CodeExecutor>,
    flavor: ValidationFlavor,
) -> Result<ServerBuilder>

Register validate_code + execute_code on builder, driven by the [code_mode] block, a caller-supplied CodeExecutor, and a ValidationFlavor (OAPI-10 / D-02).

This is the ONE backend-agnostic wiring function serving BOTH the SQL path (flavor = ValidationFlavor::Sql, executor = SqlCodeExecutor) and the OpenAPI path (flavor = ValidationFlavor::OpenApi, executor = JsCodeExecutor<HttpCodeExecutor>). The executor is type-erased to Arc<dyn CodeExecutor> so the same function — and the same execute_code handler body, which already dispatches through the trait — works for any backend; only the flavor selects the validation surface + tool format.

This is the actual two-tool registration the LOCKED crate::builder_ext::ServerBuilderExt::try_code_mode_from_config_with_connector delegates to (the Phase 83-06 R1 split precedent: the connector-aware builder method constructs the executor, this helper wires the tools).

• When config.code_mode.is_none() the builder is returned UNCHANGED (no-op) — code-mode is opt-in at the config level.
• When [code_mode] IS present, the R9 inline-secret gate and the secret-resolution / HMAC machinery run via validation_pipeline_from_config (errors surface BEFORE .build()), then both tools are registered with the static [code_mode] policy baked into the pipeline (SC-3 / D-13). A NoopPolicyEvaluator is wired so authorization is purely the static config policy (allow_writes / allow_deletes / allow_ddl), not an external Cedar/AVP engine.

Errors

Surfaces every error from validation_pipeline_from_config when config.code_mode.is_some() — most notably ConfigValidationError::InlineSecretRejected (review R9) and the ToolkitError::CodeMode secret-resolution / 16-byte-minimum failures.