MCP-path telemetry attribution can go stale after a plugin upgrade (frozen DATAVERSE_OPERATION_CONTEXT)

Summary

The plugin stamps a telemetry attribution string app=dataverse-skills/<version>;skill=<skill>;agent=<agent> on every request so the server can see which plugin version routed each call. There are two attribution surfaces, and one of them can report a stale version after the plugin is upgraded.

The two surfaces

• Python SDK / Web API (scripts/auth.py): _plugin_version() reads the packaged plugin.json at runtime, so it always reflects the installed version. (Correct as of #110.)
• MCP proxy (npx @microsoft/dataverse mcp <url>): the version is substituted as a literal into the MCP client config when the server is registered, e.g. -e DATAVERSE_OPERATION_CONTEXT="app=dataverse-skills/1.10.1;skill=mcp-direct;agent=claude-code" (see dv-connect/references/mcp-configuration.md). The npx proxy reads that frozen env value at startup; it never consults auth.py or plugin.json.

Problem

When the plugin is upgraded (e.g. 1.10.1 -> 1.11.0) but the MCP server config is not re-registered, the MCP proxy keeps sending the OLD version in its attribution. This happens on a normal reconnect because dv-connect Step 0 short-circuits a fully-configured workspace straight to Step 7, skipping the MCP registration (Step 6) that would refresh the value.

Refreshing .env's DATAVERSE_PLUGIN_VERSION does not fix this -- the MCP client config holds its own frozen copy, independent of .env.

Impact

Server-side telemetry attributes some MCP traffic to an older plugin version than is actually installed, skewing per-version usage/adoption analysis. Low severity: attribution accuracy only, no functional impact.

Repro

1. Connect a workspace at plugin version X (registers MCP with app=dataverse-skills/X).
2. Upgrade the plugin to version Y.
3. Reconnect (dv-connect) -- Step 0 detects the existing setup and jumps to Step 7, skipping MCP re-registration.
4. Make an MCP tool call.
5. Observe: the request's DATAVERSE_OPERATION_CONTEXT still carries app=dataverse-skills/X, not Y.

Suggested fix

On reconnect (dv-connect Step 0 short-circuit), detect version drift and refresh the MCP registration when the config's baked version differs from the manifest version:

• Parse the MCP server config for the current host (Claude .mcp.json / Copilot / Cursor ~/.cursor/mcp.json / Codex ~/.codex/config.toml).
• Extract the dataverse-skills/<ver> token from DATAVERSE_OPERATION_CONTEXT.
• If it differs from plugin.json version, re-run the Step 6 registration to rewrite it.

This is per-host config work (4 formats), which is why it was split out of the SDK-path fix (#110) into this follow-up.

Related

• SDK-path fix: #110 (_plugin_version() now reads the manifest instead of a stale .env value).