fix(registry): flip type==='buying' filter inversions to 'sales' + add sales to by_type tally

[EmmaLouise2018]

Refs #3538, #3495.

#3495 fixed agent-type inference (sales tools → 'sales', not 'buying'). The sweep missed 6 call sites that filtered on agent.type === 'buying' for logic that semantically operates on sales agents (the ones that hold publisher authorizations and call list_authorized_properties). Pre-fix, both classification and filter were inverted — they accidentally aligned. Post-fix, the filters silently match zero real sales agents and entire code paths went dead.

Sites flipped

File:line	What it does	Effect post-#3496
crawler.ts:419	reverse-crawl publishers from sales agents' list_authorized_properties	dead — no sales agent matches 'buying'
health.ts:131	fetchStats populates property_count, publishers, publisher_count	sales agents returned empty stats
publishers.ts:204	publisher-domain map in trackPublishers	publisher tracking missed sales agents
http.ts:8784	agent cache warmer calling propertiesService.getPropertiesForAgent	property cache cold for sales agents
registry-api.ts:3667	withProperties enrichment dispatch	publisher_domains/property_summary empty in /api/registry/agents
registry-api.ts:3677	withProperties enrichment result mapping	same path downstream

The receiving function at federated-index.ts:281 already documents the source as "a sales agent's list_authorized_properties" — the caller was the bug. Comment + log message at crawler.ts:416-417 updated to match.

Stats tally fix

/api/stats and /agents JSON by_type returned {creative, signals, buying} but never counted sales. Added a sales line to both at http.ts:2021 and :2087.

Behavior change: path 2 reverse-crawl revives

crawler.ts:417-465 is a previously-dead reverse-crawl path. With this PR merged, every sales agent's list_authorized_properties response will be walked, and each publisher_domain it surfaces will be crawled (adAgentsManager.validateDomain per domain).

Rate-limit shape — verified, not a fanout risk on first pass:

• The loop is sequential for (const agent of agents) containing a sequential for (const domain of auth.publisher_domains). Each validateDomain call awaits before the next domain starts. No Promise.all fanout.
• processedDomains (crawler.ts:437) deduplicates within a crawl pass — a publisher domain referenced by multiple sales agents only crawls once.
• Errors are caught per-domain (try { ... } catch (err) { log.error(...) }), so a single bad domain doesn't stall the loop.
• Today's fleet: 2 sales agents (Bidcliq, Swivel). Bounded.

Registry growth expectation:

• Once revived, expect /api/registry/agents and /api/registry/publishers to gain rows from any publisher domain that Bidcliq/Swivel claim authorization on. These will appear as source: 'discovered' (not registered). Pre-emptively flag for whoever monitors registry growth metrics — first crawl pass after merge is the moment to watch.
• Subsequent sales agents (when they register) will trigger their own first-pass crawl. If the fleet grows substantially, the sequential loop is still bounded but a parallelism cap + per-domain rate-limit becomes worth designing.

Out-of-scope guardrails (file separately if growth surprises us):

• Per-domain crawl cooldown (e.g., don't re-validate the same domain within 1h across passes).
• Concurrency cap on the publisher-domain inner loop.

Backwards compatibility

Non-breaking on the wire. /api/stats and /agents by_type responses gain a new sales: <count> field — additive. The other five fixes restore previously-broken behavior; consumers that depended on the broken behavior (zero property_count, empty publisher_domains) will start seeing populated data, which is the intended state.

Test plan

• New: server/tests/unit/health-stats-type-filter.test.ts pins the type filter for sales/buying/empty cases — 3/3 pass.
• npx vitest run server/tests/unit/ — 2623/2623 pass.
• npx tsc --noEmit -p server/tsconfig.json — clean.
• Pre-commit hooks green (test:unit, test:test-dynamic-imports, typecheck).
• Server-integration job is red on a pre-existing stripe-client.js mock issue (listCustomersWithOrgIds not exported in the vi.mock blocks at content-my-content.test.ts:137 and admin-endpoints.test.ts:62). Stack does not touch any file in this PR. Tracked as fix(test): add listCustomersWithOrgIds to stripe-client mock — server integration tests fail at HTTPServer.start #3548. Confirm fix lands before merging this PR so CI is green.

Stack ordering

Independent of #3541 (different lines in crawler.ts) and #3542 (different lines in registry-api.ts). Recommended merge order from #3538: 3540 → 3542 → 3543 → 3541.

Out of scope

Tracked as separate issues from #3538:

• fix(test): add listCustomersWithOrgIds to stripe-client mock — server integration tests fail at HTTPServer.start #3548 — stripe-client mock missing listCustomersWithOrgIds (blocker for this PR's CI).
• feat(registry): one-shot re-probe of all type='unknown' agents with extended timeout (Problem 2 quick-win) #3551 — one-shot re-probe of unknown agents (Problem 2 quick-win — biggest user-visible follow-up).
• decision(schemas): remove 'buying' from AgentType enum, or keep for future use? #3549 — should buying stay in the AgentType enum (now that sales is correctly classified, the value is unreachable from inference).
• decision(registry): how should discovered agents surface member-publisher endorsement (#3538 Problem 6) #3547 — Problem 6 decision (member-publisher endorsement on discovered agents).
• ops(registry): backfill writes type-reclassification audit log #3550 — type-reclassification audit log (P1 follow-up to ops(registry): backfill stale member_profiles.agents types + crawler reclassify-on-disagreement #3541).
• docs(registry): /publisher auth-aware response note (parity with /operator) #3546 — /publisher auth-aware parity check (follow-up to docs(registry): rename Lookups tag, annotate source/member/discovered_from, /operator auth-aware note #3542).