Give tracker agents a browser to read setters

The tracker-mapping and common-pattern enrichment agents only had
web search, which returns title/url/snippet, so they could never
open a cookie-database or cookie-policy page to read which vendor
actually sets a tracker. This mis-attributed setters whose snippet
is misleading (e.g. _li_* read as LinkedIn rather than LiveIntent).

Wire the read-only headless-browser toolset into both agents, gated
on a configured Chrome endpoint, mirroring the common-third-party
enrichment worker: agent construction moves into the run path so each
run can carry a per-run browser that is closed when the run returns.
The prompts now direct the agent to open a promising result and read
the named setter from the full page text. Both agents stay unchanged
when no Chrome endpoint is configured.

Signed-off-by: Émile Ré <emile@probo.com>

pkg/cookiebanner/prompts/tracker_identification.txt.tmpl

@@ -24,10 +24,12 @@ Return a structured JSON response with:
    - Stop searching once you get a confident match; do not exhaust all query slots if the first one succeeds.
    - When evaluating web search results, verify that the tracker name discussed in the result shares a meaningful prefix with the pattern you are identifying. Trackers with different prefixes are distinct — for example, _hjCookieTest (Hotjar's _hj prefix) must not be confused with a pattern named cookietest (no _hj prefix). If the search result discusses a tracker whose prefix does not match, discard it and continue searching or lower your confidence.
    - A generic token shared with a vendor's terminology is NOT a match when it appears as a suffix or substring behind a different, meaningful prefix. The leading prefix is what attributes a vendor, not a common word elsewhere in the name. For example, probo_distinct_id carries the custom prefix probo_, so it must NOT be attributed to Mixpanel merely because Mixpanel uses a distinct_id key — the prefix probo_ does not belong to Mixpanel. Likewise, a key ending in _session or _uid is not attributable to a vendor just because that vendor also uses such a word.
-   - Some web search results come from cookie-database or cookie-banner directory sites (e.g. cookifi.com, cookiepedia.co.uk, cookiedatabase.org, cookie-script.com, cookieserve.com, and similar "cookie database" / "cookie scanner" directories). These rank highly only because they catalog cookies, not because they set them. Treat such a result ONLY as a reference directory: read which actual vendor the page names as the setter of the tracker, and attribute to THAT vendor. NEVER set third_party_name to the directory operator itself (e.g. "Cookifi", "Cookiepedia", "Cookie-Script", "CookieDatabase", "CookieServe") — they are never the third party that set the tracker. If such a page names no concrete vendor for the tracker, ignore it and continue searching or return an empty third_party_name with third_party_confidence below 0.3.
+   - Some web search results come from cookie-database or cookie-banner directory sites (e.g. cookifi.com, cookiepedia.co.uk, cookiedatabase.org, cookie-script.com, cookieserve.com, and similar "cookie database" / "cookie scanner" directories). These rank highly only because they catalog cookies, not because they set them. Treat such a result ONLY as a reference directory: open the page with the browser tools (navigate_to_url, then extract_page_text) and read which actual vendor the page names as the setter of the tracker, and attribute to THAT vendor. The snippet alone is often insufficient — the database table that names the true setter usually only appears in the full page text. NEVER set third_party_name to the directory operator itself (e.g. "Cookifi", "Cookiepedia", "Cookie-Script", "CookieDatabase", "CookieServe") — they are never the third party that set the tracker. If such a page names no concrete vendor for the tracker, ignore it and continue searching or return an empty third_party_name with third_party_confidence below 0.3.
    - Exception: a consent-management vendor's OWN product cookie is still attributable to that vendor on the strength of its naming convention, independent of where the search result was hosted — e.g. OptanonConsent / OptanonAlertBoxClosed -> OneTrust, CookieConsent -> Cookiebot, cookieyes-consent -> CookieYes. Judge that on the naming convention alone, the same way you would any other vendor.
 
-4. Common cookie naming conventions to recognize:
+4. When browser tools are available (navigate_to_url, extract_page_text, extract_links, find_links_matching), use them to open a promising web_search result and read its full content rather than relying on the title/snippet. This is decisive for two cases: a cookie-database entry whose table names the true setter (e.g. a "_li_*" entry that names LiveIntent, not LinkedIn), and a site's cookie-policy page that lists the vendor behind a cookie. Read the page, identify the concrete vendor the page attributes the tracker to, and apply the same prefix-matching and directory-operator rules above to that text. Do not navigate to more than a few pages; stop once a page gives a confident attribution.
+
+5. Common cookie naming conventions to recognize:
    - _ga*, _gid, _gat*: Google Analytics
    - _fbp, _fbc, fr: Meta / Facebook
    - _pk_*: Matomo (formerly Piwik)
@@ -38,11 +40,11 @@ Return a structured JSON response with:
    - hubspot*: HubSpot
    - _cls_*: Clarity (Microsoft)
 
-5. The observed domains are useful signals but not conclusive on their own. Many sites load third-party tracker scripts through a first-party reverse proxy (e.g. t.example.com proxying PostHog). When a domain matches the scanned site, it reveals nothing about which third party set the tracker — rely on the naming convention or a database/web search instead. First-party proxy domains are filtered before they reach you, but if you still see the scanned site's own domain, ignore it as evidence. Well-known third-party tracking domains (e.g. doubleclick.net, facebook.com, analytics.google.com) remain strong evidence.
+6. The observed domains are useful signals but not conclusive on their own. Many sites load third-party tracker scripts through a first-party reverse proxy (e.g. t.example.com proxying PostHog). When a domain matches the scanned site, it reveals nothing about which third party set the tracker — rely on the naming convention or a database/web search instead. First-party proxy domains are filtered before they reach you, but if you still see the scanned site's own domain, ignore it as evidence. Well-known third-party tracking domains (e.g. doubleclick.net, facebook.com, analytics.google.com) remain strong evidence.
 
-6. A domain or full URL appearing INSIDE the pattern name is NOT a third-party signal when it matches <scanned_site>. It is the site's own first-party origin — commonly a browser extension that appended the page URL to its key (e.g. "ethereum-https://example.com", where the wallet extension suffixes the site origin), or a tracker the site owner set on their own site. The site owner is never a third party of its own site, so you must NOT attribute the scanned site's own brand or domain as a third party. If the embedded own-domain is the ONLY vendor cue, return an empty third_party_name with third_party_confidence below 0.3. A genuine naming convention elsewhere in the key (e.g. _ga, _fbp, _hj) still attributes normally — judge that on its own merits, independent of the embedded site domain.
+7. A domain or full URL appearing INSIDE the pattern name is NOT a third-party signal when it matches <scanned_site>. It is the site's own first-party origin — commonly a browser extension that appended the page URL to its key (e.g. "ethereum-https://example.com", where the wallet extension suffixes the site origin), or a tracker the site owner set on their own site. The site owner is never a third party of its own site, so you must NOT attribute the scanned site's own brand or domain as a third party. If the embedded own-domain is the ONLY vendor cue, return an empty third_party_name with third_party_confidence below 0.3. A genuine naming convention elsewhere in the key (e.g. _ga, _fbp, _hj) still attributes normally — judge that on its own merits, independent of the embedded site domain.
 
-7. Be conservative with third_party_confidence. It measures certainty about the attribution (who set the tracker), nothing else:
+8. Be conservative with third_party_confidence. It measures certainty about the attribution (who set the tracker), nothing else:
    - 0.9-1.0: exact pattern match found in database, or unmistakable naming convention + matching domain, or a name that embeds the vendor (e.g. "__darkreader__*" -> Dark Reader)
    - 0.7-0.8: strong signal from naming convention or domain, but not a database match
    - 0.5-0.6: reasonable guess based on partial naming patterns
@@ -50,10 +52,10 @@ Return a structured JSON response with:
 
    Do not lower third_party_confidence just because the artifact is a browser-extension key, localStorage entry, or otherwise not a classic web tracker. The goal is to attribute the vendor, not to judge how "tracker-worthy" the artifact is — if the name unambiguously names its source, attribute it with high confidence.
 
-8. If you truly cannot identify who set the tracker, set third_party_name to an empty string and third_party_confidence below 0.3.
+9. If you truly cannot identify who set the tracker, set third_party_name to an empty string and third_party_confidence below 0.3.
 
-9. Only attribute a tracker to a company or service when you have concrete evidence: an exact (perfect) match on the pattern in the database, an unmistakable naming convention where the tracker's meaningful prefix belongs to that vendor (including a vendor name embedded in the key), or a clear web search result whose tracker name shares that meaningful prefix. Absent a shared meaningful prefix or a perfect pattern match, do NOT imagine a vendor — never guess or invent attributions based on vague similarity, a shared generic word, or general knowledge. If no evidence supports a match, return an empty third_party_name with third_party_confidence below 0.3.
+10. Only attribute a tracker to a company or service when you have concrete evidence: an exact (perfect) match on the pattern in the database, an unmistakable naming convention where the tracker's meaningful prefix belongs to that vendor (including a vendor name embedded in the key), or a clear web search result whose tracker name shares that meaningful prefix. Absent a shared meaningful prefix or a perfect pattern match, do NOT imagine a vendor — never guess or invent attributions based on vague similarity, a shared generic word, or general knowledge. If no evidence supports a match, return an empty third_party_name with third_party_confidence below 0.3.
 
-10. For the category field, use one of: {{.Categories}}.
+11. For the category field, use one of: {{.Categories}}.
    Most cookies fall under ANALYTICS or MARKETING.
 </instructions>