#11128 perf(integration-ever-works): read the toggles of every mapping on a connection in one query

Addresses the CodeRabbit performance nitpick deferred on the develop → stage cascade #11096 (thread): Load entitySettings with each mapping read.

Problem

EverWorksMappingContextService.forConnection(), which the docs, tasks, task-comment and agent-email sweeps call for each connection, loads the tenant's mappings with only settings. It then builds each mapping of the connection, and entitySyncOf() runs its fallback IntegrationEntitySetting query once per mapping, so every sweep costs 1 + N queries.

Fix (mapping/ever-works-mapping-context.service.ts)

forConnection() reads the toggles of all its mappings in one query (integrationId IN (...)) and keeps them on each mapping. entitySyncOf() already prefers loaded rows. Results are unchanged, and a mapping with no toggle rows still gets [], which reads as "all on".

Why not relations: { settings: true, entitySettings: true } on all four reads, as suggested:

• forRequest and forOrganization build one mapping. Loading the relation costs the same one query the fallback runs, and joining it next to settings returns settings × toggles rows (about 15 × 11 per mapping).
• forEverWorksOrganization (once per inbound event) loads every Ever Works mapping of the tenant to build one. Loading the relation there would read every mapping's toggles, and with a join multiply every mapping's rows, to save the single fallback query of the mapping it builds.

So those three reads stay as they are. Only the per-mapping repeat in forConnection is removed.

Tests

mapping/ever-works-mapping.db.spec.ts (SQLite), new case in the OQ4 block: two mappings on one connection, one with Document off. forConnection() reads IntegrationEntitySetting once, and each context has its own toggles and directions (docs both / off).

It fails on develop (2 reads, expected 1) and passes with the fix. Locally (Node 26, --experimental-vm-modules): mapping 17/17.

🤖 Generated with Claude Code

---

Summary by cubic

Cuts the Ever Works sweeps' 1 + N toggle reads: forConnection() now loads the entity toggles of all mappings on a connection in one query instead of one per mapping.

• forConnection() fetches IntegrationEntitySetting rows with a single integrationId IN (...), groups them by mapping in one pass, and keeps them on each mapping; entitySyncOf() already prefers loaded rows, so behavior is unchanged (no toggle rows still means all on).
• The single-mapping reads (forRequest, forOrganization, forEverWorksOrganization) are left as is, since there the fallback costs one query and loading the relation would read toggles that aren't needed.

Adds a SQLite test covering two mappings on one connection with one toggle off, asserting the toggles load in a single query.