Design a Route Handler that doesn't leak Express habits into the App Router

You are designing one or more Next.js Route Handlers for an API requirement, to be written as app/api/.../route.ts files. These use the Web-standard Request and Response objects, via NextRequest and NextResponse, not an Express-style (req, res) signature — there is no res object anywhere in this code, and nothing here should reach for one.

ENDPOINT PURPOSE
Lets a project admin invite a new team member by email and assign their role

HTTP METHODS NEEDED
POST to create an invite, DELETE to revoke a pending one

REQUEST AND RESPONSE SHAPE
POST body: { email, role }; response: the created invite object including its id and expiresAt. DELETE takes an inviteId route param and returns no body.

RUNTIME CONSTRAINTS
Needs the nodejs runtime — the handler sends a transactional email through a Node-only mailer SDK

EXISTING AUTH PATTERN
Every route in app/api/ reads a verified session via getServerSession() and rejects with 401 if there's no session, and 403 if the session's role isn't admin

DESIGN RULES
Export one named async function per HTTP method actually needed — GET, POST, PATCH, DELETE — never a single catch-all handler that branches internally on request.method; the App Router resolves methods by export name, and a branching catch-all just reimplements what the routing layer already does for you, with worse readability and no benefit. Validate the request body or query parameters against a schema before any business logic runs; on a validation failure, return a 400 with field-level error detail, never a generic 500, and never a 200 with the actual error message buried in the response body where a caller has to parse prose to find out what went wrong. Choose the runtime explicitly with export const runtime set to nodejs or edge, and justify the choice against what the handler actually needs — the edge runtime has no access to Node-only APIs such as fs, most native modules, and some crypto functions, so choose edge only if nothing in this handler's dependency chain genuinely needs those, not by default on the assumption that edge is always faster. If this handler performs a mutation that makes data cached elsewhere in the app stale, call revalidatePath or revalidateTag for the specific affected paths or tags, only after the mutation has actually succeeded, never before, and never a broad revalidation call when a narrowly scoped one would do the identical job with less collateral invalidation. Return real, specific HTTP status codes: 201 on a successful create, 204 with an empty body on a successful delete, 409 on a genuine conflict such as a duplicate unique field, 404 when the target resource genuinely does not exist, rather than 200 for every outcome with the real result encoded only in the body's shape. Apply the existing auth pattern consistently across every exported method in this file, including read-only GET handlers — a Route Handler with an unauthenticated GET sitting next to an authenticated POST on the same resource is a common and easy-to-miss access-control gap that a per-method review can walk right past if auth isn't checked as a cross-cutting rule.

OUTPUT FORMAT
The complete route.ts code. Then a short list covering: which status codes are used and in which specific situation each one fires, which runtime was chosen and the specific reason tied to this handler's actual dependencies, and exactly what gets revalidated after a successful mutation, named by path or tag rather than described vaguely as "the relevant cache."