mcp: read_resource returns ambiguous null for untracked vs tracked-but-clean files

[bug-ops]

Description

read_resource currently returns {"diagnostics":null} in two distinct situations:

1. The file has never been opened/tracked by the LSP client
2. The file is tracked but has no diagnostics (clean)

Clients that need to know whether LSP analysis has actually run cannot distinguish these cases from the response alone.

Expected Behavior

The response shape should distinguish the two states, e.g.:

• {"diagnostics": null} → file not yet tracked (analysis not run)
• {"diagnostics": []} → file tracked, analysis complete, no issues

Or introduce a "tracked": bool field alongside diagnostics.

Actual Behavior

Both states return {"diagnostics":null}, making it impossible for a client to know if it should wait for analysis or if the file is genuinely clean.

Environment

• Version: 0.3.6
• Marked in source as TODO(critic-S2) in crates/mcpls-core/src/mcp/server.rs:601

Logs / Evidence

// TODO(critic-S2): distinguish "file not tracked" from "file tracked but clean"
// in the response shape. Currently both return `{"diagnostics":null}` which is
// ambiguous for clients that need to know whether analysis has run yet.