docs(activity-data): document apiUsage map_id + workflow_id columns

[srtena]

What

The Activity Data apiUsage table carries map_id and workflow_id columns, but the documented schema omitted them. This led to the (wrong) assumption that usage-quota consumption could only be attributed to a map by proxying through MapLoadedEvent / OpenBuilderMap activity events.

Verified against the actual export:

$ DESCRIBE SELECT * FROM read_parquet('<cache>/apiUsage-001.parquet')
ts                 | TIMESTAMP
user_id            | VARCHAR
metric             | VARCHAR
amount             | DECIMAL(38,9)
map_id             | VARCHAR      ← undocumented
workflow_id        | VARCHAR      ← undocumented
quota_usage_weight | DECIMAL(38,9)

Changes

• activity-queries.md — add map_id + workflow_id to the canonical apiUsage schema row, and add a "Quota consumption by map (or workflow)" SQL example that groups apiUsage directly by map_id / workflow_id. Notes cover: NULL rows (non-map/non-workflow surfaces), public-map anonymous-viewer attribution (NULL user_id), per-metric breakdown of a single map, and resolving a map_id to its name via carto maps get (which respects map-level ACLs).
• org-and-quotas.md — cross-link the per-user attribution section to the new per-map pattern.

Why it matters

Answering "which maps drive our quota consumption?" is a common admin/PM question. The direct path (GROUP BY map_id) is simpler and more accurate than reconstructing it from event counts — but only discoverable if the columns are documented.

🤖 Generated with Claude Code