Wire Auth.js session checks correctly across Server Components, Route Handlers, and middleware

You are wiring Auth.js (NextAuth) session checks across a Next.js App Router app, deciding what runs in middleware versus what runs in a Server Component or Route Handler, and specifically checking whether the session strategy in use is even compatible with where each check is being placed.

SESSION STRATEGY
JWT strategy — sessions are signed tokens stored in a cookie, no database lookup needed to verify signature and expiry

ROUTES NEEDING PROTECTION
/dashboard/* requires any signed-in session; /dashboard/admin/* additionally requires an admin role

CURRENT AUTH CHECKS
middleware currently calls auth() directly and checks session.user.role === 'admin' inside it — this works today but the team is considering switching to the database session strategy for revocation support

ROLE OR PERMISSION MODEL
A jwt callback attaches role to the token at sign-in, and a session callback copies it onto session.user.role

DESIGN RULES
Confirm the session strategy before deciding what middleware can actually check: a JWT session strategy encodes the session directly in a signed, stateless token, which middleware running on the edge runtime can verify on its own with no database call, but a database session strategy stores the session server-side and requires a lookup to confirm it's still valid — if the app uses the database strategy, middleware genuinely cannot verify a full, current session on its own without adding a database round trip to every matched request, which reintroduces the exact latency problem middleware exists to avoid; in that case, middleware should either not attempt full session verification at all, or the app should use a lighter, edge-compatible check (verifying only that a session cookie exists and is well-formed) in middleware while the actual, authoritative check happens in a Server Component or Route Handler that does have full database access. Use the auth() helper (or the session-reading utility Auth.js exposes for this) inside Server Components and Route Handlers for the authoritative check, reading the full session including whatever role or permission data the app's callbacks attach to it, since this is where a real database lookup, if the strategy requires one, is actually affordable — it runs once per request that reaches this layer, not on every request including ones middleware would otherwise reject before they get here. Keep role and permission logic out of middleware entirely unless the session strategy and the specific role data genuinely allow a stateless check — middleware's job here is presence and basic validity of a session, not authorization decisions that depend on data which may need a fresh lookup to be trustworthy, such as a role that could have changed since the token was issued. Apply the same session-reading pattern consistently across every protected Server Component and Route Handler rather than letting different routes call auth() with slightly different assumptions about what fields are guaranteed to exist on the returned session object — a route that assumes session.user.role is always present will throw or misbehave the moment it's hit by a session shape that predates a schema change, if that possibility hasn't been guarded against explicitly.

OUTPUT FORMAT
A table: Layer (middleware, Server Component, Route Handler) | What it checks | Why that check is affordable at this layer given the session strategy | What it explicitly does NOT check. Then one paragraph stating plainly whether the current session strategy and the current middleware implementation are actually compatible, or whether the middleware is attempting something the chosen strategy can't support on the edge runtime.