Add semantic lint diagnostics and unused-variable warnings

Summary

Introduce non-blocking semantic lint diagnostics, starting with unused bindings and parameters, while keeping compilation gating restricted to errors.

Scope

• Extend compiler diagnostic severity beyond the current error-only model.
• Add a lint phase/category whose warnings do not make Diagnostic.hasErrors fail.
• Derive usage from semantic and ownership facts, not token spelling or raw occurrence count.
• Distinguish declaration, read, write, move, and drop contexts.
• Warn for unused locals, write-only bindings, and unused parameters under a documented policy.
• Define an intentional-unused convention if Silk needs one.
• Keep public/external-interface declarations out of workspace-only unused conclusions.
• Allow warnings without fixes.
• Produce compiler-owned source actions only when evaluation, effects, ownership, and cleanup are proven preserved.
• Establish configuration/suppression behavior without lint-specific compiler shortcuts.

Safety cases

• Removing let value = run operation() must not silently remove execution.
• Removing an affine binding must not change required cleanup.
• A write-only mutable binding is distinct from a never-referenced binding.
• Removing a parameter is a call-site refactor, not a local deletion.
• Same-spelled shadowed bindings must be analyzed independently.

Acceptance criteria

• Warnings publish through the LSP with warning severity and never block build/codegen by themselves.
• Exact unused local/parameter cases receive deterministic diagnostics.
• Read/write/move/drop facts prevent false “unused” classifications.
• An unsafe-to-remove binding receives a warning without an unsafe quick fix.
• A proven-safe fix is represented through the compiler source-action/change-plan seam from #178.
• Tests cover effectful initializers, affine values, writes without reads, parameters, pattern bindings, shadowing, and public declarations.
• Lint configuration and intentional suppression are specified before implementation is considered complete.

Follow-up integration

Function-contract and ordinary/effect policy warnings should use this lint framework, but their semantic analyses remain separate issues.

Start with the compiler diagnostic severity model and Diagnostic.hasErrors behavior, then trace how diagnostics are published through the LSP. Read the compiler source-action/change-plan seam from #178 before designing fixes, and review the requested safety cases and test coverage. Done means deterministic unused-binding warnings reach the LSP without blocking builds, with only proven-safe actions and documented configuration and suppression.