Give the planner the GitHub tools it was promised

The planner's tool list named `github/*` and the runtime dropped it silently,
so the agent reached for `gh` and curl, had those refused by the gate, and
concluded aloud that it could not see GitHub — while its prompt told it it
could.

A custom agent's `tools` cannot admit an MCP tool at all. Not by wildcard, not
by exact name, not with the server declared on the agent rather than the
session: measured every way, an explicit list yields zero MCP tools while
omitting the list yields all twenty-nine. The filter that understands where a
tool came from is the session's `availableTools`, which takes `builtin:`,
`mcp:` and `custom:` patterns, so the allowlist moves there and the agent
declares none of its own.

The same entry is in Ace's planner, so its GitHub tools have never resolved
either.

None of this was visible, which is the part worth fixing properly. The session
now reports what the planner can actually call, and whether the MCP server
connected at all — one line each, against a real session rather than the boot
probe, which has no room and so none of the plan tools. A refused tool call is
shown too: permission is decided before execution, so a denial produced no
start, no completion and no trace, leaving a boundary the agent kept hitting
and nobody could see.

Verified against the issue that prompted this: the agent calls
`github-issue_read` and summarises githubnext/calmhn#34. Forty-one tools
resolve, twenty-nine from GitHub, and none of them write — the read-only
header holds, with the gate behind it.