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

[lukecotter]

Background

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).

Problem

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.

Goal

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.

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.

Options

1. 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.
2. 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 above.
3. Both, gated on which case a log is.

Suggested next step

Adopt option 1 for the UI now (correctness), and research option 2 (certified-vs-shared pool detection) before showing a combined ceiling. Fix the parser rollup so global limits aren't summed and namespaced limits expose byNamespace instead of a misleading single total.

[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.)