fix(registry): flip 5 buying-vs-sales inversions missed by #3540 sweep — closes #3774

[EmmaLouise2018]

Closes #3774. Surfaced by Brian-style red-team of #3766.

Same inversion class as PR #3540 swept across filter sites — but 5 sites slipped through because they had a different shape (function-call arguments and local-inference re-implementations rather than equality comparisons against stored type). Two were visible bugs in the public discovery diagnostic endpoints; three were silently aligned with the registry's defensive re-filter and would become live bugs if the defensive filter ever changed.

Sites flipped

File:line	Shape	Effect today	Fix
http.ts:2007	listAgents("buying") filter	No-op (crawler re-filters)	flip → "sales"
http.ts:8729	listAgents("buying") filter + buyingAgents var	No-op (crawler re-filters)	flip + rename to salesAgents
mcp-tools.ts:831	listAgents("buying") filter	No-op	flip → "sales"
http.ts:8442	Local-inference branch	Visible bug: type: 'buying' returned for sales agents	consolidate + flip
registry-api.ts:5802	Local-inference branch (duplicate of above)	Visible bug (same)	consolidate + flip
mcp-tools.ts:2058	Resource-handler type allow-list missing 'sales'	agents://sales returns "Unknown resource type"	add 'sales'

What changed structurally

The two duplicated local-inference blocks at http.ts:8442 and registry-api.ts:5802 are now consolidated into a single helper:

server/src/lib/diagnostic-agent-type-inference.ts
  inferDiagnosticAgentType(toolNames: string[]): 'sales' | 'creative' | 'signals' | 'unknown'

Both diagnostic endpoints call it. Polarity is now in one place — future polarity changes need exactly one fix, not two. Loose substring matching preserved as-is (separate concern from polarity; the canonical strict-match inference at CapabilityDiscovery.inferAgentType is unchanged).

Why this wasn't caught in #3540

#3540's sweep used grep -E 'type [!=]==? \"buying\"' for filter-site inversions on stored agent.type. These 5 sites are different:

• listAgents("buying") — function-call argument, not a comparison
• Local-inference branches — assign 'buying' based on tool surface, not compare against stored type

A wider sweep at the time (or a smell-test for "any string literal 'buying'") would have caught them.

Test plan

• New: server/tests/unit/diagnostic-agent-type-inference.test.ts — 12/12 pass. Pins the polarity matrix including an exhaustive NEVER returns 'buying' invariant assertion. If anyone reverts polarity, cases marked // pinning #3774 fail loudly.
• npx tsc --noEmit -p server/tsconfig.json — clean.
• Pre-commit hooks green.

Backwards compatibility

Non-breaking on the wire. Only behavior change: the public discovery diagnostic endpoints now return type: 'sales' for sales-tool-exposing agents instead of type: 'buying'. Any consumer that was relying on the broken 'buying' response was already wrong — 'sales' is the correct AdCP polarity per #3540 and #3495.

Pairs with

• fix(registry): flip type==='buying' filter inversions to 'sales' + add sales to by_type tally #3540 — the original 6-site flip
• feat(registry): preserve member-declared 'buying' type — closes #3549 #3766 — buying-type preservation (closes decision(schemas): remove 'buying' from AgentType enum, or keep for future use? #3549)

This sweep makes the registry's agent.type polarity consistent across the filter sites, the inference paths, the resource handler, and the diagnostic endpoints. No remaining 'buying' references except the deliberate by_type stat tallies (which correctly count buying-typed agents).

Out of scope

• Tightening the diagnostic helper's loose substring matching to align with CapabilityDiscovery.inferAgentType's strict matching. Loose matching preserved here intentionally — diagnostic endpoints serve pre-onboarding probes where tool-name conformance is incomplete. Worth a follow-up if false-positive rate becomes a concern.
• Replacing the diagnostic helper with the canonical inference helper (different match semantics — strict vs loose). Same follow-up.