[EL-33] Add local-inference health, capabilities, planning, scheduling, and benchmark UX

[sodejm]

Catalog ID: EL-33

Public issue: #128

Reviewed baseline: 71abaf4067d4118f28910a22c20524b4e0282b28

Core objective: Integrate existing local-inference capabilities into one
desktop surface without implementing a second inference engine or bypassing
provider policy.

Priority / phase: P2 / Local inference integration

Publication status: Published as #128.

Dependency mapping

• Blocks: None
• Depends On: #108, Performance: make Ollama profiles operational for constrained hardware #30, Performance: add shared Ollama clients and bounded local inference scheduling #31, Performance: add a reproducible minimum-hardware local LLM benchmark suite #33, Performance: minimize structured prompts and local-model output budgets #34, Performance: add capability-aware local model request planning #36, Performance: add context-aware chunking and resumable local workload planning #37, Feature: support secure OpenAI-compatible local inference runtimes #38
• Relates To: Research: benchmark LangChain and LiteLLM against native provider adapters #24, Performance: bound GEDCOM duplicate blocking and minimize LLM adjudications #32, Performance: route every GEDCOM local-LLM call through the modular LLM service #35

UX/UI requirements

• Display local endpoint health, capabilities, selected model, resource
  estimates, queue state, and benchmark provenance.
• Distinguish measured, estimated, stale, and unavailable values.
• Provide validated planning/scheduling, cancellation, and accessible history.
• Never imply automatic selection from an installed model, endpoint, or key.

Public interfaces

• Add renderer-safe health, capability, execution-plan, schedule, queue, and
  benchmark DTOs.
• Accept configured profiles, allowlisted local endpoints, typed workloads, and
  bounded parameters only.
• Return coded stale, compatibility, capacity, timeout, and cancellation errors.

Underlying app changes

• Add integration endpoints over existing local inference services.
• Normalize service output into versioned transport DTOs.
• Preserve provider policy and provider=none network denial.
• Use bounded backend refresh rather than renderer endpoint probes.

Acceptance criteria

• Configured local endpoints can be checked without renderer networking.
• Capability and benchmark results include time, version, model, hardware
  context, and freshness.
• Plans reject incompatibility and resource limits before scheduling.
• Queue/job state survives renderer reload and sidecar restart.
• Cancellation reaches a deterministic terminal state.
• No provider is auto-selected because an endpoint or key exists.
• provider=none passes network-denial instrumentation.
• Accessibility tests cover health, planning, scheduling, queue, and
  benchmark comparison.

Security mitigations and rejected anti-patterns

• Applies TM-L01, TM-A01, TM-A02, TM-I01, and TM-O01.
• Reject renderer fetch, arbitrary URLs, redirects, LAN discovery by default,
  credential inference, hidden cloud fallback, unbounded polling, payload
  telemetry, and renderer-owned scheduling truth.

Workspace mapping

• Exclusive owned paths: desktop/src/features/local-inference/**,
  src/ancestryllm/api/routes/local_inference/**,
  tests/api/local_inference/**, and
  desktop/tests/local-inference/**.
• Shared-file rule: Existing service owners receive exact adapter requests;
  generated contracts, provider registries, dependencies, and lockfiles remain
  coordinator-managed.
• Base rule: Branch from updated main after all dependencies merge.
• Branch: feature/electron-el-33-local-inference-ux
• Worktree: /Users/justinsoderberg/Development/worktrees/ancestryllm-electron-el-33-local-inference-ux
• Validation: make test; make lint; make typecheck; make security;
  pnpm --dir desktop test; pnpm --dir desktop typecheck; network denial

[sodejm]

Recommended Codex configuration

• Planning: gpt-5.6-terra with high reasoning
• Implementation: gpt-5.6-sol with high reasoning
• Rationale: This work spans multiple files or subsystem boundaries and needs substantial architecture or performance reasoning, while remaining below the highest security and data-integrity risk tier.
• Delivery: Use test-case-driven development: translate the acceptance criteria into failing or characterization tests first, implement incrementally, then run the applicable tests, lint, typecheck, security, integration, and hosted gates.