fix(graph): scope tunnel reads and deletes to config

[fallenmi]

What does this PR do?

• threads the optional palace config through list_tunnels, follow_tunnels, and delete_tunnel
• keeps deletion's lock, load, and save on the same selected tunnels.json
• passes the MCP server's canonical _config through all four tunnel handlers
• adds regressions with two palaces containing the same deterministic tunnel ID, proving reads and deletion cannot cross palace boundaries
• documents the fix in the changelog

The root cause was an incomplete config-propagation path: create_tunnel(..., config=selected) already wrote to the selected sidecar, but its matching readers either ignored or could not accept that config. With ambient palace B active, follow_tunnels(..., config=A) therefore returned B's same-ID record; deletion could likewise mutate B while leaving A untouched.

Calls that omit config retain the existing default-palace behavior. This completes the tunnel read/delete side of the palace-isolation work merged in #2018.

Closes #2263

How to test

• .venv/bin/python -m pytest -q tests/test_palace_graph_tunnels.py tests/test_mcp_server.py — 425 passed
• .venv/bin/python -m pytest -q tests/test_palace_graph_tunnels.py tests/test_closets.py — 130 passed
• .venv/bin/python -m pytest -q tests/test_miner.py — 128 passed
• broad regression run excluding the unrelated installation-layout subprocess check — 4,297 passed, 31 skipped
• .venv/bin/pre-commit run --all-files — Ruff check and format passed

Checklist

• Tests pass
• No hardcoded paths
• Linter passes