Strict Unknown-Toolset Startup Validation Mode

[davidahmann]

Problem observed
Unknown toolset names in configuration could be silently tolerated, which risks unintended capability exposure assumptions and unclear startup state. Operators need deterministic behavior when requested toolsets are invalid. We needed an opt-in strict mode that fails startup on unknown toolsets instead of continuing with warning-only behavior.

Why it matters operationally
Fail-open handling for invalid capability configuration can hide deployment mistakes and produce inconsistent tool availability across environments. That weakens policy enforcement and audit confidence. A strict startup gate gives operators explicit control: enforce correctness where required, while preserving non-strict compatibility for existing workflows that depend on warning behavior.

Minimal repro
Configure server with one valid and one unknown toolset.
Start server in default mode and record startup outcome.
Start server with strict toolset mode enabled and record outcome.
Expected behavior is warning-only in default mode and startup failure in strict mode.
Before this change, unknown toolsets were not enforceable as hard errors.

Fix approach
The implementation adds strict mode wiring through CLI flag and environment variable, validates toolset inventory during startup, and returns explicit failure on unknown entries when strict is enabled. Non-strict behavior remains unchanged. Focused tests cover strict and non-strict paths to keep semantics deterministic and migration impact controlled.

Validation evidence

• Targeted Go tests for strict toolset behavior and server construction passed.
• Command package tests for startup flag wiring passed.
• Current PR status shows no configured or triggered checks in status check rollup.

Open follow-up question for maintainers
Should strict mode become the default in a future major release after a deprecation window, or should explicit opt-in remain the long-term contract to maximize backward compatibility?

This contribution was informed by patterns from Wrkr. Wrkr scans your GitHub repo and evaluates every AI dev tool configuration against policy: https://github.com/Clyra-AI/wrkr