feat: validate app_id format in verify API

[odaysec]

Added validation for app_id format in verify API. do not use app_id from the HTTP request body directly in the verification URL. Instead, validate and normalize it at the API boundary so it matches an expected pattern (for example, app_ followed by alphanumerics, dashes, or underscores), and reject or sanitize any value that does not conform. Ensure that the endpoint override is not user-controlled in the example path (it currently isn’t), and keep the hostname fixed.

Best concrete fix with minimal behavior change:

1. In examples/with-next/pages/api/verify.ts, validate app_id from req.body against a strict regular expression that enforces the known app_... format. If the value is invalid, return an error response instead of calling verifyCloudProof.
2. Continue passing the validated app_id into verifyCloudProof so the rest of the flow remains unchanged.
3. Since verifyCloudProof already types app_id as `app_${string}`, we don’t modify that function’s signature or internals; we only ensure that what we pass in satisfies the expected constraints.

All changes are confined to examples/with-next/pages/api/verify.ts; packages/core/src/lib/backend.ts remains unchanged from the snippet, because once app_id is validated, the URL construction is safe and remains functionally identical for valid inputs.

Concretely:

• Add a small validation block after extracting { proof, app_id, action, signal } in handler.
• Use a conservative regex like /^app_[A-Za-z0-9_-]+$/ to constrain allowed app_id values.
• If validation fails, respond with HTTP 400 and a simple JSON error message.

[vercel]

@odaysec is attempting to deploy a commit to the Worldcoin Team on Vercel.

A member of the Team first needs to authorize it.