fix(registry): server-side agent-type resolution at registration

[EmmaLouise2018]

Summary

Refs #3495. Merges after #3496 and #3497 (third in the stack).

This is the prevention layer. PR #3496 fixed the discovered-side inference; PR #3497 backfilled member-registered rows. Without this PR, a client can re-introduce the bug at any time by PUT-ing type: 'buying' for a sales agent — member-profiles.ts previously accepted any string verbatim.

Root cause of the prevention gap

• PUT /api/me/member-profile (line 439) — no validation of agents[].type
• POST /api/me/member-profile (line 183) — same
• PUT /api/admin/member-profiles/:id (line 1696) — same
• MemberDatabase.normalizeAgentConfig (server/src/db/member-db.ts:38-39) — copied the string through with as AgentConfig['type']
• AgentConfig.type declared as AgentType | 'buyer' (server/src/types.ts:379) — the legacy 'buyer' slack normalized into the type system
• Hard-coded 'buying' defaults in dev-setup.ts:88, 109-110 (Training Agent + Acme seeds) and adcp-tools.ts:767 (OAuth context creation before discovery)

Changes

server/src/routes/member-profiles.ts — resolveAgentTypes() helper

New helper called from all three write paths. For each agent in the array:

1. Look up agent_capabilities_snapshot for the URL via AgentSnapshotDatabase.bulkGetCapabilities
2. If a snapshot exists and its inferred_type validates against the AgentType enum, override the client's type with it. The capability snapshot is ground truth — the client's value is a hint at best.
3. If the client's type is a string but doesn't validate, replace with 'unknown'
4. Otherwise leave as-is

Wired into POST /, PUT /, and admin PUT /:id.

server/src/db/member-db.ts — defense in depth

normalizeAgentConfig (called on every JSONB → AgentConfig deserialization) now validates type via isValidAgentType and drops invalid values instead of casting them through. So even pre-existing legacy strings ('buyer', 'seller') won't propagate to the API response.

server/src/types.ts — tighten the type

• AgentConfig.type from AgentType | 'buyer' to AgentType
• isValidAgentType parameter widened from string | undefined | null to unknown so it can be used as a type guard in deserialization where the input shape is JSONB-derived

server/src/dev-setup.ts — fix wrong seed values

• Training Agent: type: 'buying' → 'sales' (it's an embedded sales-agent reference impl per mcp-tools.ts:1200)
• Acme: type: 'buyer' → 'buying', type: 'seller' → 'sales' (those legacy values aren't in the AgentType enum)
• Acme offerings: seller_agent → sales_agent (seller_agent isn't in VALID_MEMBER_OFFERINGS — the prior value was being silently rejected during validation)

server/src/addie/mcp/adcp-tools.ts:767

OAuth-context creation no longer hardcodes agent_type: 'buying' — defaults to 'unknown' and lets the discovery probe set the real value when it runs.

Why this stacks on top of #3496 + #3497

• The override step calls into agent_capabilities_snapshot.inferred_type, which is populated by the crawler using inferTypeFromProfile(). That function only returns 'sales' for sales agents after fix(registry): infer discovered agents with sales tools as type 'sales' #3496 merges. If this PR ships before fix(registry): infer discovered agents with sales tools as type 'sales' #3496, the prevention layer would still produce 'buying' for sales agents — same wrong answer, just enforced server-side.
• fix(registry): backfill member-registered sales agents + agents.html UI #3497's UI updates make 'sales' actually render correctly in the public registry. Without fix(registry): backfill member-registered sales agents + agents.html UI #3497, anything this PR labels 'sales' would render as 'Unclassified'.

Each PR is independent codewise; the stacking is purely runtime/correctness ordering.

Test plan

• npm run typecheck
• npx vitest run server/tests/unit/ — 2564/2564 pass (one pre-existing flaky member-context test passed on retry)
• npx vitest run server/tests/unit/member-profiles.test.ts — passes
• Pre-commit hooks (test:unit, test:test-dynamic-imports, typecheck)
• Verify on staging after fix(registry): infer discovered agents with sales tools as type 'sales' #3496 + fix(registry): backfill member-registered sales agents + agents.html UI #3497 + this merge: PUT /api/me/member-profile with type: 'buying' for a known sales-agent URL stores 'sales' in JSONB; new agent registrations surface as 'sales' in the registry once their capabilities are probed

[bokelley]

Approved.

Defense-in-depth done right: prevention at write (resolveAgentTypes), normalization at deserialization (normalizeAgentConfig), and tightening AgentConfig.type from AgentType | 'buyer' to AgentType so the legacy slack can't sneak back in via the type system.

The seed/default fixes are real bug catches:

• Acme seller_agent was being silently rejected against VALID_MEMBER_OFFERINGS — that's the kind of thing you only find when you tighten the type
• adcp-tools.ts:767 defaulting OAuth context to 'buying' before discovery is exactly the wrong direction; 'unknown' until probed is the principled answer

One runtime dependency to call out: resolveAgentTypes overrides the client's type with agent_capabilities_snapshot.inferred_type. Existing snapshot rows for sales agents currently store 'buying' (populated by the buggy inferTypeFromProfile before #3496). Asked Emma over on #3496 to extend migration 453 to backfill that column too — without it, this PR's prevention layer will enforce the stale wrong answer on member registrations between deploy and next crawl cycle.

With that snapshot backfill landed in #3496, this is the right capstone for the stack. Merge order: 3496 → 3497 → 3498.