Make LSP trace controllable: verbosity level + per-category mute (currently firehose, likely CPU cost)

Summary

The LSP trace is firehose-or-nothing and far too noisy. We need granular control: a verbosity level and the ability to mute specific categories of trace output. Right now it both buries useful signal and likely wastes CPU/IO serializing megabytes of JSON.

What exists today

Only one knob: basilisk.trace.server = off | messages | verbose (vscode-extension/package.json:678-687). That's the stock vscode-languageclient toggle — all-or-nothing, and it controls only LSP message tracing, not the server's own tracing output.

The noise (observed)

• Full publishDiagnostics payloads dumped per file — every diagnostic for every file is serialized into the trace as pretty-printed JSON, including test fixtures, build output (vscode-extension/out/...), and vendored code (debugpy/...). A single notification can be hundreds of lines.
• High-frequency command spam — execute_command 'basilisk.profiler.processes' logs every ~2 seconds continuously while the Python Processes panel is visible (hundreds of identical lines).
• Repeated basilisk.typeHealth, basilisk.workspaceModules, etc.

This makes the trace unreadable and is plausibly burning CPU (JSON serialization + IO on every keystroke-driven re-check across 587 files).

Requested behavior

1. Verbosity level for the server's own logs (error | warn | info | debug | trace), surfaced as a setting (e.g. basilisk.log.level) and applied to the tracing subscriber — not just the LSP message trace.
2. Per-category toggles / filters, e.g.:
   • diagnostics (the publishDiagnostics dumps)
   • commands (execute_command, incl. the profiler-process polling)
   • profiler / processes polling
   • workspace-scan
   • dap / debug proxy
     Allow muting categories independently (a tracing EnvFilter-style directive, or a list of enabled/disabled targets).
3. Don't log full diagnostic payloads at info. Summarize ("published N diagnostics for ") and gate the full dump behind debug/trace.
4. Throttle / collapse the periodic poller (profiler.processes) — don't emit an identical info line every 2s; log on change only, or at trace.

Severity

Enhancement / performance — the current trace is unusable at volume and likely costs CPU.

Related

The diagnostic-payload noise overlaps with #80 (vendored files being scanned at all). This issue is specifically about trace controllability, independent of which files are scanned.

Start with vscode-extension/package.json:678-687, then locate the Rust tracing subscriber and the handlers for diagnostics and profiler.processes logging. Done means server log levels and categories can be controlled independently, diagnostic traces are summarized at info, and unchanged polling does not emit repeated info lines.