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

<context>
Endpoint purpose: Lets an authenticated user update their team's billing address
HTTP methods needed: GET and PATCH
Request/response shape: PATCH body: { line1, city, postalCode, country }; response: the updated team object
Runtime preference, if any: Needs Node.js — the handler calls a Postgres client that isn't edge-compatible
</context>

<task>
Design the Route Handler(s) for this endpoint as they'd live in app/api/.../route.ts, using the Web-standard Request/Response APIs (NextRequest/NextResponse), not an Express-style (req, res) signature — there is no res object here.
</task>

<requirements>
- Export one named async function per HTTP method actually needed (GET, POST, PATCH, DELETE, etc.) — never a single catch-all handler that branches on req.method internally.
- Validate the request body/query against a schema before touching any business logic; return a 400 with field-level errors on validation failure, not a generic 500.
- Choose and state the runtime explicitly (export const runtime = 'nodejs' | 'edge') based on what the handler actually needs — edge runtime has no access to Node.js-only APIs (fs, most native modules, some crypto), so justify edge only if nothing in the handler needs those.
- If this handler causes data that's cached elsewhere in the app to go stale (a mutation), call revalidatePath or revalidateTag for the specific affected paths/tags after the mutation succeeds — never before, and never a broad revalidation when a narrow one would do.
- Return real HTTP status codes (201 on create, 204 on empty delete response, 409 on conflict, etc.) — not 200 for everything with an error message in the body.
</requirements>

<output_format>
The route.ts code, followed by a short list: which status codes are used and when, which runtime was chosen and why, and exactly what gets revalidated after a mutation.
</output_format>