fix(mcp): make agent failures diagnosable from the log, not just from the source (#2087)

* fix(mcp): make agent failures diagnosable from the log, not just from the source

Mining event_log for mcp.tool_called: VALIDATION_ERROR ran at about one a day
until 2026-08-25, then jumped to a hundred a day and stayed there. One
integration's gnubok_get_kpi_report has been refused 604 times over seven days
and is still failing.

The cause is the unknown-parameter guard from #1856, which is correct and
stays. The caller is even told precisely what is wrong: getStructuredError puts
"Unknown parameter "x" for <tool>. Valid parameters: ..." into message_en,
which the agent receives.

What was broken is what we recorded about it. Two things, both cheap:

- Telemetry logged only message_sv, which for VALIDATION_ERROR is the registry
  default "Förfrågan innehåller ogiltiga uppgifter." and names neither the
  parameter nor the tool. A seven-day outage was indistinguishable from a typo,
  and the cause was only findable by reading the dispatcher source. errorDetail
  now carries message_en, stored only when it differs from errorMessage, so the
  many domain failures whose message_sv is already the specific text cost
  nothing extra.
- errorKind said 'company_access_denied' for all 604, because the arg guard
  throws inside the company-routing try. That is an active misdirection: it
  sends triage looking for a tenancy bug that does not exist. Exactly two
  things in that block raise VALIDATION_ERROR, the unknown-parameter guard and
  a malformed company_id, and neither is a permissions failure, so they now log
  as 'invalid_arguments'.

Tests reproduce the production call shape and were verified to fail when either
fix is reverted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(mcp): derive the telemetry payload type from the event contract

Two review findings, both valid.

The local ToolCalledPayload interface was a hand-maintained duplicate that
omitted sessionId and half the errorKind union. That is not cosmetic: it is why
errorDetail could be added to the emitter and to lib/events/types.ts while the
test file type-checked against a stale shape. Deriving it from
EventPayload<'mcp.tool_called'> removes the drift.

The null-detail assertion was also conditional, so it would have passed on a
wrong-but-present value. Replaced with two determinate cases: a scope denial
carries both languages without duplicating either, and the unknown-tool exit,
which supplies no diagnostic, stores null.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* test(mcp): pin the scope name in the diagnostic assertion

'A different string' passes on any placeholder. The reason errorDetail is worth
storing is that it names what the caller lacks, so assert that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

DECISIONS.md

@@ -1407,6 +1407,7 @@ One line per decision: `[YYYY-MM-DD] <decision>: <why>`. Appended by agents and
 [2026-08-31] gnubok-home-ok cache cookie is user-scoped (userId~host) instead of cleared on sign-out: sign-out happens client-side via supabase.auth.signOut so no server surface reliably sees it, while a value bound to the session's user makes any inherited verdict miss the cache by construction. Separator ~ because it is unreserved under encodeURIComponent AND a legal raw cookie octet, so the value round-trips identically whether or not the cookie layer percent-encodes. Old host-only cookies never match and self-heal; found via the amnas account-switch repro (two logins 9 s apart shared the verdict).
 [2026-08-31] Bookkeeping digest email is per-user per-COMPANY per-day (not one aggregated mail across companies): notification_log.company_id anchors the claim, subject lines stay unambiguous, and most users have one company; consultants can opt in and get one short mail per client. Window is a fixed last-24h (cron cadence) rather than tracking last-sent state. Settings toggle stays hardcoded Swedish like the rest of the push-notifications extension UI (no next-intl wiring in extension components); revisit if that surface is ever translated.
 [2026-08-31] Own-credentials seam forward-ported into the entitlement partition (skeptic refutation on PR #1747): a self-host serving bank_sync/skatteverket from its OWN env credentials (the same vars the extensions activate on) counts those as local capabilities, so upgrading an own-credentials self-host never dark-launches the connector gate against a working integration (the 2026-08-17 folded-flag incident shape). lib/entitlements/own-credentials.ts mirrors the connector-mode seam arriving in the instance-wiring PR (connector mode = key AND no own creds) and must stay in sync with it. org_lookup/migration have no own-credentials form. capability_blocked copy now has a self-host variant naming GNUBOK_CONNECTOR_KEY instead of the hosted subscription upsell, which misled operators toward a product they cannot buy for a self-host.
+[2026-08-31] MCP tool telemetry now logs errorDetail (structured.error.message_en) alongside errorMessage (message_sv), and splits errorKind 'invalid_arguments' out of 'company_access_denied'. Found by mining event_log: the 2026-08-25 unknown-parameter guard (#1856) refused one integration's gnubok_get_kpi_report 604 times over seven days, and every row logged a permissions-shaped errorKind with the generic registry message "Förfrågan innehåller ogiltiga uppgifter.". The caller was told exactly which parameter was wrong (message_en carries it); only our own telemetry was blind. errorDetail is stored only when it differs from errorMessage, so domain failures whose message_sv is already specific cost nothing.
 [2026-08-31] Connector key validation maps a database/RPC error to 503 CONNECTOR_VALIDATION_UNAVAILABLE, never 401 (skeptic refutation on PR #1748): the instance sync deletes its entire connector grant cache on 401/403 (revocation semantics), so the api-keys fail-closed-to-401 precedent would let a transient hosted DB blip destroy a paying instance's 72h offline grace; 503 lands in the sync's keep-grants branch. In the same pass X-Connector-Key now wins over Authorization in extractConnectorKey: the header exists solely for proxied calls where Authorization carries an upstream token (the SKV data proxy sends both), and Bearer-first hashed the upstream token and 401'd exactly that shape.
 [2026-08-31] Connector sync deletes its grant cache only on a 401/403 whose JSON body carries a connector rejection code (CONNECTOR_KEY_MISSING/INVALID/SUSPENDED), never on status alone (second skeptic refutation on PR #1748, same failure class as the RPC-error mapping one layer up): a Vercel WAF challenge page, edge deployment protection, or a self-host egress proxy all answer 401/403 without the hosted app running, and status-trusting deletion let any of them wipe a paying instance's 72h offline grace within the hour. A codeless 401/403 now lands in the keep-grants server_error branch and the cache expires naturally if the condition persists.
 [2026-08-31] Connector usage metering redacts opaque path segments to ':id' before insert (skeptic refutation on PR #1751): the proxied bank paths carry the raw EB session id and account uid as segments, so persisting the raw pathname in connector_usage_events put the cleartext handle next to the ledger that exists precisely to store only sha256(handle). redactEndpoint() replaces UUID/long-hex/long-base64url segments; literal route words survive so metering keys stay useful.