Respect config precedence

When configuration can vary by user/environment, resolve it deterministically (following documented precedence), keep it configurable instead of hardcoded, and apply it dynamically if it may change at runtime.

Practical rules:

• Env var / credential resolution: follow the precedence you intend to support (documented behavior beats “guessing”). If you change precedence, call out multi-provider edge cases.
• Environment-specific constants: don’t hardcode regions/endpoints when they can differ across deployments—make them configurable (or at least driven by model/endpoint metadata that can evolve).
• User controls/feature flags: avoid hardcoded keybindings and similar UX toggles; support config files and sensible defaults.
• Config schema: keep settings shapes simple and stable (avoid unnecessary nesting).
• Runtime settings: if a setting is user-editable mid-session (e.g., via /settings), don’t decide behavior once during session creation—re-evaluate from the session settings manager when converting requests.

Example (dynamic blockImages handling):

// Bad: captures blockImages once at session creation
// const convertToLlmWithBlockImages = blockImages ? filteredConvertToLlm : convertToLlm;

// Good: decide per-use from session manager
function makeConvertToLlm(sessionManager: { getBlockImages(): boolean }) {
  return async function convertToLlm(...args: unknown[]) {
    const shouldBlock = sessionManager.getBlockImages();
    if (shouldBlock) return convertToLlmFilteredImages(...args);
    return convertToLlmUnfilteredImages(...args);
  };
}

Following this standard prevents stale configuration behavior, reduces deployment brittleness, and makes feature flags and user settings reliably predictable.