fix: resolve slug kind before fetching product detail

[kalwiggins]

Fixes the source of a defect that has now propagated into every storefront generated from this template.

The problem

In the catch-all [slug] route, every category and brand page view fires a guaranteed-404 product lookup first — twice per request, once in generateMetadata and once in the page. In this template that costs little, because the default repositories read bundled JSON. In a downstream storefront with a live backend wired in, each one becomes a real API call.

Measured on RVGearPro, generated from this template and pointed at Foundry — one hour of CloudFront access logs:

6,703 of 6,709 storefront requests were 404s
127 unique paths, 53:1 repeat ratio
all shaped /products/<category-slug>
user-agent "node"  ← the storefront's own server-side fetches

~99.8% of its catalog API traffic achieved nothing, and each 404 was a real database query at the origin.

Root cause

The resolution order is backwards relative to cost:

Lookup	Cost
categoryRepository.getBySlug	cached list → in-memory find, no network
brandRepository.getBySlug	cached list → in-memory find, no network
productRepository.getBySlug	live backend call once a real provider is wired in

The expensive question was asked first, unconditionally.

The fix

resolveSlugKind() asks the two free questions first and falls through to "product" only when the slug is neither — where a miss is a genuine 404. Both entry points share it, so the work happens once per request instead of twice.

The diff is deliberately small: one line per branch, all rendering and SEO bodies untouched.

Precedence change

A slug matching both a category and a product now resolves to the category, where it previously resolved to the product. Preserving the old precedence would require always paying for the product lookup, which is the cost being removed. Flagging it because it is a behaviour change, not a pure optimization.

Downstream

Existing storefronts do not inherit this automatically — each was generated, not linked. The same fix has been raised separately against the ones with a live backend (Foundry, MiniPIM or BigCommerce). Storefronts wired only to static JSON were deliberately skipped: there is nothing to save there.

This PR stops future generated storefronts being born with it.

Verification

tsc --noEmit reports no errors in the changed file.