Deploy a Supabase Edge Function through the Management API multipart deploy endpoint instead of the CLI

Known gotchas

• verify_jwt defaults to enabled. With it on, the platform validates the Authorization header and returns 401 before your handler runs. Third-party webhooks (Stripe, GitHub, Twilio) will fail silently-looking 401s until you set verify_jwt:false and implement your own signature check.
• entrypoint_path is required and must name a file you actually uploaded in a 'file' part. A mismatch fails the deploy rather than falling back to index.ts.
• This endpoint is multipart/form-data, not JSON. The metadata part must itself be serialized JSON — sending the whole request as application/json returns a validation error.
• Deploying replaces the live function. There is no version rollback exposed on this endpoint, so keep source in git and be able to redeploy the previous commit.
• The CLI equivalent (supabase functions deploy <name>) reads per-function settings from supabase/config.toml under [functions.<name>] — entrypoint, import_map, verify_jwt. The API takes those as metadata instead, so the two paths can drift if you use both.
• Custom entrypoints via the CLI require Supabase CLI >= 1.215.0; older CLIs silently ignore the setting while the API accepts it, producing environment-dependent behaviour.
• Setting or changing Edge Function secrets does NOT require a redeploy — do not chain an unnecessary deploy after a secret rotation.