feat(web): consume v2 API for the config-resource bundle

[Makisuo]

What

Migrates the dashboard off the v1 client (MapleApiAtomClient) onto the already-shipped v2 endpoints (MapleApiV2AtomClient) for the four config-resource groups whose v2 surface landed in #224 but was never consumed by the UI:

v1 group	→ v2 group	UI surfaces
ingestKeys (get, reroll*)	ingestKeys (retrieve, roll*)	ingestion settings, install modal, connect-credentials, ingest connection
ingestAttributeMappings	attributeMappings	attribute-mappings settings, recommended-mappings, recommendation route
scrapeTargets	scrapeTargets	scrape-targets settings, integration catalog
recommendationIssues	recommendations	recommended-mappings, recommendation route

Why

The #224 config-resource bundle was built, tested, and documented, but the dashboard still called the v1 client for all of it — so the v2 write path was effectively dark. This wires the UI to it, matching the documented convention that each v1 group is deleted once nothing consumes it.

Notable deltas (beyond mechanical snake_case / param renames)

• Payloads: v2 param schemas are Schema.Struct, so mutations pass plain snake_case objects (not new V2…Params({...})).
• IDs round-trip to raw internal IDs at the client boundary (the PublicId codec decodes responses back to raw UUIDs and re-encodes on request). So row.id and the /recommendations/$recommendationKey route param are unchanged from v1.
• List pagination: v2 lists are cursor-paginated (default 20). attributeMappings + recommendations page through all pages via a runtime.atom cursor loop (module singletons, so useAtomRefresh still shares one fetch). scrapeTargets keeps .query(...) with limit: 100 to preserve its reactivityKeys invalidation (a runtime.atom would drop it).
• Reconciliation stays refetch-based (no txid): manual useAtomRefresh for mappings/recommendations/ingest keys; reactivityKeys for scrape targets. Both clients share appRegistry, so the PlanetScale card's v1 integrations mutations still invalidate the migrated v2 scrape-target list.

Out of scope (intentionally left)

• alert_incidents and scrapeTargets.listChecks stay on ElectricSQL shapes.
• The integrations OAuth group in the catalog (Cloudflare/PlanetScale/Hazel/GitHub status) stays v1.
• Deleting the now-unused v1 groups is a follow-up (gated on confirming no non-web consumers).

Verification

• bun typecheck (apps/web): clean.
• Browser e2e against local api, all four groups: reads (200 + correct snake_case/envelope shapes, page-through pagination confirmed via recommendation rows feat: add Hazel as an alert destination type #27–fix(api): block private/loopback URLs in scrape targets, alerts, ClickHouse + cross-tenant label override #32) and writes — attributeMappings.update (PATCH), recommendations.dismiss/reopen, scrapeTargets.create/probe/delete — all → 200, hitting /v2/... with refetch reconciliation. ID round-trip verified (route links + Target ID show raw UUIDs; request paths show amap_/rec_/scrp_ encodings).

Note: config-resources.http.test.ts currently fails on main due to unrelated in-progress InvestigationService wiring (the v2 investigations/anomalies work), not this change — this PR is web-only.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[pullfrog]

Your Pullfrog Router balance is exhausted.

You have a card on file but auto-reload is disabled, so runs paused once your balance went past the overdraft buffer.

Top up balance → · Enable auto-reload →

  ^{｜ ⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to @v0 or keep the SHA fresh with Dependabot ｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}