Generate an API reference straight from the route handlers, not from what you remember they do

Generate an API reference for the endpoints below by reading their actual current implementation — reference the route files with #file or #codebase so you're documenting the real request handling and response shape, not a remembered or assumed version of it.

ROUTE FILES TO DOCUMENT
api/routes/orders.ts and api/routes/orders.[id].ts

AUTH MODEL FOR THESE ROUTES
Bearer JWT required on all routes except GET /orders/public-status, which is intentionally unauthenticated.

RESPONSE-SHAPE NOTES
All success responses are wrapped in { data: ..., meta: { requestId } }; errors use { error: { code, message } }.

WHERE THE OUTPUT SHOULD LIVE
docs/api/orders.md

For each endpoint, read the handler function itself, not just its name or route path — a route named /users/:id/orders could still, in its current implementation, only return the last 30 days of orders, or silently exclude cancelled ones, and that kind of behavior is only visible in the function body, never in the route signature. If the code validates the request body with a schema (Zod, Joi, a class-validator DTO, whatever this codebase uses), pull the actual field names, types, and required/optional status from that schema rather than restating them from memory or from any existing doc comment above the function, since a stale doc comment describing an older version of the schema is a common and specific way documentation drifts out of sync with the code it's supposed to describe.

For each endpoint, note explicitly if the current implementation's behavior looks like it might not match what the route name or an existing comment implies it does — flag that as a discrepancy to confirm with me rather than silently documenting either the name's implication or the code's actual behavior as if there were no conflict.

OUTPUT FORMAT (as a markdown table per endpoint, matching the target file at docs/api/orders.md)
| Field | Value |
|---|---|
| Method + path | |
| Auth required | |
| Request body / params | |
| Success response shape | |
| Error responses | |
| Notes / discrepancies found | |

After the tables, list separately any endpoint where the implementation didn't match its name or existing docs closely enough that you'd want a human to confirm the intended behavior before this reference is treated as authoritative.