✨ feat(database): per-namespace governor limits / overall limit view (certified managed packages)

[lukecotter]

✨ Feature Request

Show governor usage correctly for multi-namespace logs — ideally an at-a-glance overall figure (e.g. 150 / 450) and/or a per-namespace breakdown, without ever overstating headroom.

🧩 Problem This Solves

Governor limits in Apex are per certified-managed-package namespace for most counters, and global for a few. Per the governor limits doc (Per-Transaction Certified Managed Package Limits):

• Per-namespace: SOQL queries, SOSL queries, DML statements, DML rows, query rows, callouts, email invocations.
• Global (whole transaction): CPU time, heap, execution time, unique namespaces.

The debug log reports usage per namespace via LIMIT_USAGE_FOR_NS blocks (parser stores these in governorLimits.byNamespace).

The current rollup (ApexLogParser.addGovernorLimits) sums used across namespaces but pairs it with a single namespace's limit. On multi-namespace transactions this renders misleading values in the Database tab, e.g. SOQL 119 / 100 (four namespaces each ≤ 100). Shipped as-is in #162 / #861 — this ticket is the follow-up to handle it properly.

🧠 Proposed Solution

Per-namespace + tightest-% headline (safe, no research needed): show the namespace closest to its limit as the headline gauge, full per-namespace breakdown on hover. Never overstates; correct in both subscriber and dev-org cases.

Adopt this for the UI now (correctness), and research the combined ceiling (below) before showing one. Fix the parser rollup so global limits aren't summed and namespaced limits expose byNamespace instead of a misleading single total.

🔄 Alternatives

1. Combined used / sum(limit) (e.g. 150 / 450): nicer at-a-glance, but only valid once we can confirm the pools are genuinely separate — needs the research below.
2. Both, gated on which case a log is.

📎 Additional context

Research so far

• Detecting pools: a namespace with its own LIMIT_USAGE_FOR_NS block has its own reported pool; a namespace that appears (e.g. ENTERING_MANAGED_PKG) but has no block is folded into default (already counted there — no double-count). No external "is certified" flag needed.
• Can't hardcode: the same package varies by org — SCMC and dlrs each had their own pool in one org's log and folded into default in another. java__util is a Salesforce-internal namespace (always folds).
• ⚠️ The catch (verified in a namespaced scratch org): in a namespaced org the org's own code is attributed to its namespace, not default (we saw insert/SELECT/update/delete land under pse while (default) stayed 0). And a dev/namespaced org reports per-namespace blocks that back one underlying pool — so summing limits (sum(limit)) can overstate available headroom (pse 100 + default 100 = 200 when there's really 100). We cannot reliably distinguish "separate certified pool (subscriber org)" from "one shared pool (dev/namespaced org)" from the log alone — this is the open research question.
• Global limits (CPU/heap/exec) must be treated as whole-transaction, never summed.

[lukecotter]

Two Salesforce ideas are relevant — one covers this issue's blocker, one is adjacent:

Covers this issue (pool identity + combined ceiling):
https://ideas.salesforce.com/s/idea/a0BHp000017Jm2vMAC

Asks the debug log to expose each namespace's governor-limit pool and the combined transaction ceiling (in LIMIT_USAGE_FOR_NS / CUMULATIVE_LIMIT_USAGE), so a tool can distinguish separate certified pools from one shared pool and show a correct used / real-ceiling instead of a misleading SOQL 119 / 100. This is the missing signal for the denominator problem in this issue — without it we cannot tell the two cases apart from the log.

Adjacent (per-statement usage — the numerator):
https://ideas.salesforce.com/s/idea/a0BHp000017Jly5MAC/debug-log-record-perstatement-soql-dml-governorlimit-contribution

Records each statement's governor contribution on SOQL_EXECUTE_END/DML_END (soqlQueries:1|queryRows:200, 0 for free __mdt/cached), i.e. which statements actually counted. Improves per-statement usage attribution (and the #162 __mdt-free-query heuristic), but does not resolve the pool-structure question.

Evidence (real multi-namespace logs): executed SOQL/DML don't reconcile against per-namespace CUMULATIVE_LIMIT_USAGE — e.g. a c2g transaction shows 201 SOQL_EXECUTE_BEGIN but only 112 counted, and a DML on a pse__ object raises pse's DML counter while the executing (default) namespace stays 0 — with no per-statement or pool attribution in the log to explain the difference.

(Heap is unaffected — it's a global, whole-transaction limit and its usage is now reported as the transaction peak.)