feat(tools): declare preconditions, so a missing id becomes a handoff

[sarve-shreyas]

The problem

Nothing routes an MCP call. The client's model picks a tool from the descriptions alone.
So a tool that needs an identifier the caller doesn't have is a dead end: the model either
asks the user for something they also don't know, or gives up. It does not reach for a
fallback, because no description tells it one exists.

The case that prompted this — "List all projects in my workspace":

TM tools requiring project_identifier	15 of 17
…that accept its absence	0
Tools in this server that list projects	0

The first step of nearly every Test Management journey was unserved. The model had nothing
to prefer and no handoff to follow, so it only reached askBrowserstackAI when a user
named it explicitly — which is not something a user should have to know.

The change

One sentence appended per tool, naming where the missing id comes from. A sibling tool
whenever one can produce it — faster and more predictable than an agent, exactly as
askBrowserstackAI's own description argues. askBrowserstackAI only where no tool can.

Product	Tool(s)	Points at
tm	15 tools	project id → askBrowserstackAI (nothing lists projects)
	getTestPlan, listSubTestPlans, getSubTestPlan	also: test plan id → listTestPlans
a11y	fetchAccessibilityIssues	scan ids → startAccessibilityScan, else the agent
	getAccessibilityAuthConfig	id → createAccessibilityAuthConfig, else the agent
tra	listTestIds	build id → getBuildId / listBuildId
	fetchRCA	test ids → listTestIds
	getFailureLogs, fetchSelfHealedSelectors, prepareSelfHealingPlan	session id → nothing lists it, so the agent

Composed, listTestCases now reads:

List test cases in a project, optionally scoped to a specific folder. … Requires a
project identifier (PR-*). No tool here lists projects, so if you do not have one, call
askBrowserstackAI with product "tm" and ask which projects exist, then retry this tool
with the identifier it returns.

Held as shared constants in src/tools/tool-handoff.ts, not per-tool prose: the wording
is the routing signal, and twenty hand-written variants drift into twenty different
signals. Rewording later is one edit.

Deliberately not included

A listProjects tool. It would also fix this query and is arguably the better
primitive — but it's a separate decision about the tool surface, and this change is the
general fix: it helps every tool that needs an id the caller lacks, not just the project
case. Worth doing as well, not instead.

What this does not fix

Tool choice is a model decision, and it varies between runs — we've seen the same query
land on different tools across two passes. This raises the probability that a stuck model
finds the next step; it cannot guarantee it. Any claim of deterministic routing would need
a different architecture, not better descriptions.

Testing

• Full suite green: 482 tests / 32 files, typecheck clean.
• Descriptions are data, so the real check is that each sentence landed on the
  description argument and not on the schema. Verified programmatically: all 25
  insertions follow a string literal, none follows a bare identifier.

Two mechanical mistakes were caught and corrected on the way, both worth knowing if anyone
repeats this pass:

1. The bare tool-name string also appears inside handlers (trackMCP, error paths), so
   anchoring on "toolName", rewrote live code. Insertion is anchored on server.tool(.
2. In rca-agent.ts the schema argument is a bare identifier (FETCH_RCA_PARAMS) rather
   than XSchema.shape, so the first attempt appended the sentence to the schema. The
   resulting type error also revealed that fetchRCA takes testId[], not a build id — so
   it points at listTestIds, which was a genuine content fix, not just a syntax one.

Base

Branched off askrelay/central-mcp (PR #379), because the handoff text names
askBrowserstackAI and that tool does not exist on main. If #379 lands first this rebases
cleanly; if #379 is deferred, the askBrowserstackAI pointers need to become
listProjects or be dropped, and the sibling-tool pointers still stand on their own.