feat: report the server's own software version on both surfaces

[fedorov]

What

Makes the server's own software/build version queryable — distinct from the IDC data version (idc_version / idc_index_data_version). Motivated by the question "can I tell which build of the server is running?", which previously had no answer on the REST side and no tool-reachable answer on the MCP side (it lived only in the MCP initialize handshake's serverInfo.version, which the client consumes but the agent never sees).

Changes

• core/version.py (new): shared package_version() / build_stamp() / server_version() — one source of truth for the software/build version.
• Model: VersionInfo gains api_version (the idc-api package version) and build (the IDC_API_BUILD stamp, nullable). DiscoveryService.version() populates them.
• REST: /v3/version returns the new fields; GET / adds server_version; OpenAPI info.version is now driven by server_version() instead of a hardcoded "3.0.0" literal (also resolves the prior 3.0.0 vs 3.0.0.dev0 mismatch).
• MCP: get_idc_version returns the fields, so an agent can retrieve the server version via a tool call (not only the handshake); _server_version() now delegates to the shared helper.
• Tests: version parity (core == REST == MCP), plus root and OpenAPI version assertions.
• Docs: user-guide /v3/version row + BUILD config row; deployment.md "which build is live?" note now covers the REST path.

Behavior (with IDC_API_BUILD=abc1234)

GET /v3/version -> {"idc_version":"v24","idc_index_data_version":"24.2.0","api_version":"3.0.0.dev0","build":"abc1234"}
GET /            -> server_version: "3.0.0.dev0+abc1234"
OpenAPI info.version -> 3.0.0.dev0+abc1234

The MCP serverInfo.version reports the identical string (shared helper).

Verification

ruff clean; the REST/parity/MCP/guard suites pass offline (46 passed, 1 skipped = clinical parity, expected in a bundled-only build).

🤖 Generated with Claude Code