Make curated-resource browsing incremental and crawlable

## Context and corrected finding

The audit claimed that `/curated_resources/page/2/` through `/page/136/` form a 136-click sequence. That exact claim does not reproduce against the current deployment: `/resources/` is the canonical landing page, `/resources/page/2/` returns 404, and the current landing page is a roughly 3.8 MB headless page that renders the full resource collection with client-side filtering.

The underlying concern is still valid: visitors receive a very large initial document, and the resource collection does not have a server-rendered, crawlable browse structure by type, education level, subject, or language.

## Requested change

- Replace the all-resources client-rendered monolith with an incremental, server-rendered browse experience.
- Provide crawlable links to stable subsets (for example, numbered pages or carefully selected taxonomy landing pages).
- Keep individual resource URLs stable.
- Do not create indexable combinations for every arbitrary filter; use canonical/noindex rules for filter variants where appropriate.
- Ensure each subset has useful title/description metadata and ordinary links to its resource pages.

## Acceptance criteria

- Initial HTML is materially smaller than the current `/resources/` response.
- A crawler without executing filter JavaScript can discover all resource pages through links and/or the sitemap.
- Keyboard users can browse and filter the collection without losing access to results.
- Representative subsets have unique canonical URLs and no duplicate-content explosion.

Reference: https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading