feat(provider): allow scoped LLM provider injection (#243)

[rodboev]

Summary

Embedding applications can now bind a governed in-process LLM provider for the current scan context. That lets hosts reuse their existing completion API without exporting raw keys, invoking an agent CLI, or monkeypatching SkillSpector internals.

Closes #243

Root cause

Provider selection lived entirely behind SKILLSPECTOR_PROVIDER and the built-in fallback chain. Every public helper routed through _select_active_provider(), but that selector had no scoped override for a provider object that the embedding application already owns.

The first implementation also left three provider-context edges open: bound HTTP providers could be treated as available even when their native chat-model construction failed, bound CLI providers could be sent through the HTTP provider path, and model context length was cached only by label even though the same label can resolve differently under different providers.

Diff Notes

• Add a ContextVar-backed provider binding API in skillspector.providers.
• Keep the existing env/default provider dispatch when no provider is bound.
• Route LLM availability through the active provider path, including CLI-capable providers, bound HTTP providers with native chat-model probes, and the existing unbound fallback.
• Keep MCP scan accounting honest by using the same availability result that the graph will use for provider selection.
• Resolve model context length from the current provider context at call time rather than caching only by model label.
• Cover metadata, active-provider, credential, chat-model, reset, nested-token, availability, MCP accounting, CLI binding, unavailable bound providers, and provider-specific context length behavior in focused tests.

Scope

This does not add a new provider family, credential store, CLI transport, or graph-level policy. The hook stays in the provider adapter layer, and MCP scan accounting only observes whether a provider is bound for the current context.

Attribution

The upstream issue proposed the ContextVar binding shape; this PR implements that design in the existing provider selector.

Verification

• pytest tests/unit/test_llm_utils.py tests/unit/test_mcp_server.py tests/unit/test_model_info.py tests/unit/test_providers.py - pass
• ruff check src/ tests/
• ruff format --check src/ tests/
• Invariant enumeration gate - pass, 24 rows, state domains checked
• Local adversarial review - no findings
• CI Lint & Test (Python 3.12), Lint & Test (Python 3.13), and DCO Check - pending maintainer approval and rerun after push

[rng1995]

[Automated SkillSpector Review]

Requesting changes. Context-local provider dispatch is the right shape, but unusable bindings are reported as available, injected CLI providers take the wrong construction path, and model-limit caching can leak values across provider contexts. These make scoped injection unreliable and can produce dishonest LLM accounting.