Catch the Date.now()-in-cache trap before Cache Components ships it to production

<context>
Next.js version and caching mode: Next.js 16, cacheComponents enabled in next.config
Code to audit (routes, layouts, components, and any 'use cache' functions): app/products/[id]/page.tsx plus lib/get-product.ts which is wrapped in 'use cache'
Freshness requirements in plain language — what's allowed to be stale, and for how long: Product descriptions can be up to 10 minutes stale; stock count and 'last updated' timestamp must always be current
</context>

<task>
Audit this code for caching correctness under the Cache Components model, where a component or function is dynamic (re-runs per request) by default UNLESS it's explicitly opted into caching with a 'use cache' directive at the top of the file or function. Do not assume the old "static unless you opt out" model — that default flipped.
</task>

<the_trap_to_check_for>
Inside any function or component marked 'use cache', flag every call to a dynamic API — Date.now(), new Date(), Math.random(), cookies(), headers(), searchParams read directly — as a bug, not a style note. Once that function is cached, whatever value those calls returned on the request that populated the cache entry gets frozen into every cached response until the entry's cacheLife expires or a matching cacheTag is revalidated. A "last updated" timestamp or a per-user value computed inside a 'use cache' scope will silently show the same frozen value to everyone who hits the cache, not just the first requester.
For each instance found, explain: what gets frozen, for how long (based on any cacheLife profile set), and the fix — either move the dynamic read outside the 'use cache' boundary (pass it in as an argument instead), or confirm the staleness is actually intended and the profile is scoped tightly enough.
</the_trap_to_check_for>

<other_checks>
- Does every 'use cache' function have an explicit cacheLife() profile, or is it relying on the default (call this out either way)?
- Are cacheTag() calls specific enough to invalidate correctly (e.g. tagged per-item, not one global tag for an entire dataset) given the freshness requirements above?
- Is anything cached that reads request-specific data (a user ID, an auth token) without that data being part of the cache key — a cross-user cache leak risk?
</other_checks>

<output_format>
A findings table: File/function | Issue | Severity (bug / needs-profile / leak-risk) | Fix. Then a one-paragraph summary of whether the current caching setup matches the stated freshness requirements.
</output_format>