Remaining env-fallback reads on a url + MCP-token context without x-n8n-key

Follow-up from the PR #1031 reviews. PR #1031 made every Public-API-dependent path of `n8n_test_workflow`, the consent write, and the project lookup behind `n8n_list_catalog` / the data-table column actions refuse (or reroute to the MCP server) when a per-request context carries `x-n8n-url` and `x-n8n-mcp-token` but no `x-n8n-key`, instead of falling back to the environment's Public API client. Two residuals remain, both read-only:

1. `handleListCatalog` with `kind: 'tags'` still reads tags through the env-fallback client on such a context (`src/mcp/handlers-official-tools.ts`, tags branch).
2. `handleListCatalog` short-circuits on its own `getN8nApiClient` null check and reports the generic "n8n API not configured" text rather than `PUBLIC_API_CONTEXT_HINT`, so the two paths word the same condition differently.

Suggested fix: apply `publicApiMatchesContext` in `handleListCatalog` before any Public API read (refuse with the shared hint, or route tags through the MCP server's `list_workflow_tags`), and consider making `getN8nApiClient` return null for a url-without-key context so the rule holds for every management tool.

Conceived by Romuald Członkowski - www.aiadvisors.pl/en