ts audit should record gtag tag ids alongside the GTM container id

[prk-Jr]

Problem

#1109 adds allowed_tag_ids to the Google Tag Manager integration. Only container_id and the ids listed there are served from the publisher's own origin; a gtag/js request naming any other tag id is answered with a redirect to the upstream.

That is a safe default — the tag still loads for the visitor — but it is a silent one. A publisher whose pages load gtag/js with a measurement id separate from their container keeps working after upgrading and simply stops getting first-party delivery for those tags, losing the ad-blocker resilience the integration exists to provide. A <link rel="preload"> for such a tag also pays an extra round trip.

ts audit already solves the equivalent problem for the container: it detects GTM on the page and writes container_id into the draft config. It should do the same for the tag ids, so the setting is populated from what the site actually loads rather than left to an operator to notice.

Current behavior

• analyzer.rs matches containers only: GTM_REGEX is \bGTM-[A-Z0-9]+\b.
• extract_gtm_container_id scans detected-integration evidence, then falls back to scanning asset.url for assets attributed to google_tag_manager.
• build_draft_config in audit/mod.rs writes container_id into [integrations.google_tag_manager], or records the integration for manual review when no id is found.

Nothing collects the id parameter from gtag/js requests, so allowed_tag_ids is always left unset.

Suggested change

Add tag-id extraction next to the existing container extraction:

• Match the id query parameter on requests and link/script URLs whose path ends in /gtag/js (or /gtag.js) on the Google tag hosts. These show up both as script src values and as <link rel="preload" as="script"> hrefs.
• Collect the distinct ids, drop any that equal the detected container_id, and write the remainder as allowed_tag_ids = [...].
• Write nothing when the set is empty, so the common single-container deployment keeps a clean config.
• When GTM is detected but tag ids cannot be determined, note it for manual review the same way a missing container id already is.

Why it is worth doing

The ids are already present in the material the audit collects. On a site checked while validating #1109, both measurement ids were visible in the served HTML as preload hrefs — the same shape the audit already parses for other integrations. Extracting them turns a manual, easy-to-miss configuration step into an automatic one.

Notes

• Only affects ts audit output; no runtime behavior changes.
• Worth confirming what the audit sees on a site that has not yet been fronted by Trusted Server, where the URLs are absolute to the Google host rather than first-party paths.