[Bug] Align REVALIDATE_SECONDS with actual cache behavior

[kilemensi]

What happened

REVALIDATE_SECONDS is documented as controlling both the server-side Prometheus cache and the ISR page-revalidation window, but the route behavior does not fully use that setting:

• app/page.tsx exports the literal revalidate = 60.
• app/site/[id]/page.tsx also exports revalidate = 60, but the production build classifies this route as dynamically server-rendered rather than ISR.
• Prometheus fetch calls and the unstable_cache wrappers do use config.revalidate.

With REVALIDATE_SECONDS=300, the production build still generates / with a one-minute ISR interval. The detail route renders on demand while its data is cached according to the configured interval.

This means a higher configured value reduces data-query frequency but does not increase the overview page's route-revalidation interval. The page can also regenerate its displayed updated timestamp while reusing older cached metric data.

What you expected

The implemented cache behavior and documentation should agree. Operators should be able to determine separately and accurately:

• how often Grafana data may be refreshed;
• whether a route uses ISR or request-time rendering; and
• how often the public updated value can change.

If Next.js cannot support an environment-driven route-segment ISR value, the setting should be documented as a data-cache interval rather than claiming to control both layers.

Steps to reproduce

1. Run MOCK=1 REVALIDATE_SECONDS=300 pnpm build.
2. Inspect the route summary and .next/prerender-manifest.json.
3. Observe that / reports Revalidate 1m and initialRevalidateSeconds: 60.
4. Observe that /site/[id] is reported as dynamically server-rendered on demand rather than ISR.

Environment

• App version / commit: 7ad4ff8
• Node version: v24.18.0
• Running mode: [ ] live (Grafana) [x] sample data (MOCK=1 / no creds)
• Host: [x] local [ ] Vercel [ ] other (specify)

Diagnostics

Not applicable; this concerns Next.js route and data-cache configuration.

The installed Next.js 16.2 documentation states that route-segment revalidate values must be statically analyzable. An environment-backed export const revalidate = config.revalidate is therefore not a supported direct fix.

Logs / screenshots

Build output with REVALIDATE_SECONDS=300:

Route (app)      Revalidate  Expire
┌ ○ /                    1m      1y
├ ○ /_not-found
└ ƒ /site/[id]

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

Generated manifest entry for /:

"initialRevalidateSeconds": 60

Acceptance criteria

• The intended route-cache and data-cache behavior is explicitly decided.
• REVALIDATE_SECONDS has one accurate, consistently documented meaning.
• The overview's updated value represents metric freshness rather than only render time.
• README.md, .env.example, docs/configuration.md, and docs/architecture.md match production behavior.
• Tests or build-time assertions cover the chosen cache behavior where practical.