Make the MCP dispatch check's tool discovery deterministic

[handstandsam]

Follow-up to #221. The android-tests-mcp-dispatch job it added is failing on main — run 30730194349. Everything else in that run is green.

The job never reached either assertion. It failed at tool discovery: it required assertVisible, which lives in the verification toolset and is only advertised when the resolved target declares it. TrailblazeMcpServer.resolveTargetScopedToolClasses scopes the advertised surface per MCP session, and a bare CI checkout resolves a narrower set than a developer machine carrying a persisted target selection — so the check passed locally and failed in CI.

Chasing that down surfaced a second, independent problem: a freshly-created MCP session does not reliably inherit the device the CLI pinned to the terminal. Locally I hit a run whose tools/list held only the session-management tools and no TrailblazeTools at all, which would have failed the job the same way for a completely different reason.

Changes

• Bind the device to the MCP session itself with connectToDevice instead of relying on the CLI's terminal pin carrying over. That is the daemon's own per-session bind and it fires the tools/list_changed that registers the driver-scoped surface.

• Assert on tap instead of assertVisible. tap and tapOnPoint both come from the baseline catalog every Android driver resolves with no target-declared toolsets, so they are advertised regardless of workspace. tap against an absent ref fails inside the on-device runner exactly the way assertVisible did, so the regression under test is unchanged:

  [FAILED] Failed to execute tap
  On-device execution of TapTrailblazeTool failed: … Element ref 'zzz999' not found on current screen …
  

• Comments now record why a verification/memory tool must not be reintroduced here, and the discovery error message no longer claims "the device never bound" when the real cause is a narrower surface.

• -t default on the connect makes the target explicit. It does not by itself pin the advertised surface — that is per-MCP-session — so the comment says so rather than implying the pin is what makes this deterministic.

Testing

Four consecutive runs of the script against an Android 35 emulator, each with a fresh daemon: exit 0 every time, identical 49-tool surface, both assertions passing. The run-to-run variance that produced the empty-surface session is gone. shellcheck clean.

The one thing local runs still cannot reproduce is CI's narrower target surface — even with -t default this machine advertises assertVisible. That tap is present in CI's surface comes from the failing job's own tool dump, not from a local run.