Ret bc-mcp: config-skabelon matcher broen + fejl svaelges ikke laengere

Live incident i aften: businesscentral MCP fejlede med et generisk
30-sekunders "connection timed out", ingen brugbar fejl. To reelle, adskilte
fejl fundet ved at teste direkte mod BC's endpoint:

1. ~/.bc-mcp.config.json havde "company": "CURABIS ApS" (Vist navn), men BC's
   faktiske Navn-felt er "Curabis ApS". BC svarede korrekt og hurtigt (400,
   under 200ms) - problemet var aldrig BC.

2. bc-mcp-bridge.js svaelgede det svar stille: en fejl-krop formateret som
   almindelig JSON, men markeret content-type text/event-stream, blev sendt
   til parseSSE() som kun leder efter "data:"-linjer - fandt ingen, returnerede
   en tom liste. Broen skrev derfor INGENTING, hverken stdout eller stderr, og
   Claude Code ventede blot sin egen 30-sekunders timeout ud.

Rettet:
- forward() tjekker nu !r.ok FOER content-type-forgrening, ubetinget - en
  fejlrespons naar aldrig parseSSE, uanset hvad serveren paastaar om sin
  egen content-type. Testet direkte mod det reproducerede scenarie: fejlen
  vises nu med det samme (5s test-vindue, ikke 30s timeout), med det fulde
  BC-fejlsvar synligt i baade stdout (JSON-RPC error) og stderr.
- bc-mcp.config.template.json matchede slet ikke broens faktiske felter
  (tenantId/baseUrl vs. broens tenant/company/configurationName) - enhver ny
  udvikler der udfyldte skabelonen efter dens egne feltnavne ville faa en
  config der intet virkede med. Rettet til de rigtige feltnavne, plus en
  eksplicit advarsel om Navn vs. Vist navn i company-feltet.
- Mode A's opsaetningsbesked (Step 3b) opdateret til at naevne alle
  placeholder-felter, ikke kun secret'en.
- To nye BCQuality-videnfiler dokumenterer begge fejl til fremtidig
  fejlsoegning.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

custom/setup/bc-mcp-bridge.js

@@ -92,7 +92,14 @@ async function forward(msg) {
   const sid = r.headers.get("mcp-session-id"); if (sid) sessionId = sid;
   const ct = r.headers.get("content-type") || "";
   const text = await r.text();
-  if (!r.ok && !text) throw new Error(`HTTP ${r.status}`);
+  // 2026-07-31: BC has returned error bodies as plain JSON while still labelling
+  // content-type text/event-stream (e.g. "company not found"). parseSSE only
+  // extracts lines starting with "data:" - a plain JSON error body has none, so
+  // it silently returned []. The stdin loop then wrote nothing at all, and the
+  // client (Claude Code) waited out its own 30s timeout instead of seeing the
+  // real error immediately. Check !r.ok BEFORE any SSE parsing, unconditionally -
+  // never let a non-2xx response fall through to parseSSE.
+  if (!r.ok) throw new Error(`HTTP ${r.status}: ${text || "(empty body)"}`);
   return ct.includes("text/event-stream") ? parseSSE(text) : (text.trim() ? [text.trim()] : []);
 }