plugin: two axiomcode versions over one graph rebuild once, say so, and an orphan writes nothing (#1835)

[swapnilpaliwal-sd]

Closes #1973

Part of #1835.

An agent session started before an engine or plugin upgrade keeps the old
version's MCP server and hooks running beside the new ones. The old one
rebuilt the graph with its engine and the new one rebuilt it back, a full
rebuild on every turn (reproduced: 3 rebuilds in 3 turns against a 0.1.9
build). The answers only said the graph was stale. And the old process
recreated .axiomcode (refresh.log, refresh.json) while the user deleted it.

• ax_orphan.orphaned(): one check for a plugin directory marked .orphaned_at,
  or one whose scripts are gone. When it fires, the refresher, hooks, timer,
  query, relink and write_state write nothing. The MCP server answers with
  "restart the agent session", stops its timer and refuses to start.
• ax_fresh.displace/contested: a build that replaces another axiomcode's graph
  records who built that graph. If the same builder rebuilds it again later,
  this version stops rebuilding it in the background and says two versions
  are running. axiomcode index still rebuilds it.
• The newer-graph note and the newer command now name the two-versions
  case and say to restart the session.
• README: restart the agent session after upgrading the engine or the plugin.

Test: tests/two_versions.py (fails 14 of 19 on the base, passes 19 of 19 now).

Suites (failures identical on the untouched base): freshness.py 117/118, mcp.py ok, mcp_first.py 24/24, run.py --lang python 445/445, refresh.py --lang python 38/46 (the same 8 changed/tests checks fail on the base).

Limits: versions already released have no orphan check, so they keep writing until their session restarts. What stops the rebuild fight is this version's hold on a contested graph, which stays as the other version left it until someone runs axiomcode index. The message says to.