eidolons v1.42.2

Patch release: stop .mcp.json from churning on a no-op OCI install/sync/upgrade — the fix for the "my MCP got disabled after eidolons sync" symptom (#371).

Fixed

• fix(mcp): eidolons mcp install/sync/upgrade no longer churn .mcp.json on a no-op. The OCI-image driver (mcp_driver_oci_image_install) re-rendered and re-wrote .mcp.json on every run with no idempotency guard. Because jq is deterministic the bytes were identical on a no-op (so the existing byte-equality test passed), but the mv-based write advanced the file's mtime every time — and a host harness (e.g. Claude Code) that watches .mcp.json for changes treats that as a changed server and re-prompts for approval. The driver now compares the digest already baked into the .mcp.json server entry against the freshly-resolved catalogue digest and, when they match (and --force is not set), skips the render+merge entirely — .mcp.json is left byte- and mtime-identical. A genuine digest bump, --force, a missing .mcp.json, or an unresolved digest all still re-render. Note: a legitimate digest bump still rewrites .mcp.json and the harness will re-prompt — that approval state lives in the host's own per-project trust file, which the CLI does not write. eidolons sync itself never touched .mcp.json; the realistic churn vector was always the install/refresh path (which runs nexus_refresh first, so a roster digest bump is auto-picked-up and feels like "it happened after I changed something").
• fix(mcp): defense-in-depth — _mcp_merge_into_json_file now carries a canonical jq -cS no-op guard (matching the established harness_install.sh pattern): a merge whose canonical form is unchanged skips the mv entirely, so .mcp.json (and .cursor/mcp.json) keep their inode and mtime even when the higher-level digest guard is bypassed (e.g. a concurrent re-render). --force still re-writes.

Upgrade: eidolons upgrade self

Full changelog: CHANGELOG.md