fix(web): api v1 filters and extension lookup ignore category spec templates #1184

Follow-up to #1166 / PR #1182 (open findings from its review).

PR #1182 makes /compare, the leaderboard, the spec export and REST API v1 (/products, /products/[slug], /compare) return the category's spec view from applyCategorySpecTemplate (@repo/shared-data/rules). Two gaps remain:

P2: API v1 filters match the stored columns

GET /api/v1/rate/products filters (has5g/5g, ram/ramGb, rom/storageGb, hz, compactScreen) still run against the stored columns, while the response body carries the scoped view. Example: ?category=smartwatches&has5g=true returns watches whose body says has_5g: false; ?category=earbuds&ram=1 returns earbuds whose body has ram_gb: null. Decide per filter: ignore filters a category's template does not have (or return 400), so the filter and the body agree.

P2: Extension lookup endpoint is not scoped

apps/web/src/server/rate/extension.ts (used by /api/v1/rate/extension/lookup) returns the stored product, so the browser extension can still receive earbud RAM/screen or watch 5G. Apply applyCategorySpecTemplate with the product's category there too.

P3: Tests

The leaderboard and API v1 checks in apps/web/src/lib/__tests__/spec-template.test.ts only match source text with regexes. Add behavioural tests (call the route handlers or the extension mapper with a phone-shaped earbud and watch).

Acceptance

• An API v1 filter never returns a product whose body contradicts it.
• The extension lookup returns no earbud screen, RAM, ROM or camera value and no watch 5G.
• Behavioural tests for the API filters and the extension lookup.