What does this PR do?

Adds the POST /v2/apps.updateApp endpoint, which allows callers to update an existing app's name, slug, defaultBranch, and deleteProtection fields. All fields except appId are optional — omitted fields are left unchanged. Changing the slug will affect deployment domains generated for the app, and a duplicate slug within the same project returns a 409 conflict.

This PR also introduces the update_app RBAC action and the app.update audit log event, wires up the new route, and exposes the permission in the dashboard root-key dialog for both workspace-wide and per-project scopes.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (refactoring code, technical debt, workflow improvements)
• Enhancement (small improvements)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How should this be tested?

• 200: Call the endpoint with a valid root key (project.*.update_app) and verify each field can be updated independently, all fields together, and that omitted fields retain their current values (including non-default values set in a prior request).
• 400: Send requests with a missing appId, an appId that is too short or contains invalid characters, a slug that is uppercase / contains underscores / has leading or consecutive hyphens / exceeds 256 characters, an empty or overly long name, and malformed JSON — all should return 400.
• 401: Send a request with an invalid bearer token and confirm a 401 is returned.
• 403: Confirm that project.*.update_app and project.<project_id>.update_app grant access, while unrelated permissions (read_app, create_app, etc.) and no permissions return 403.
• 404: Confirm that an unknown app ID and an app belonging to a different workspace both return 404.
• 409: Create two apps in the same project, then attempt to update one's slug to match the other's — confirm a 409 conflict is returned with the app_already_exists error type.
• Verify that a successful update writes an app.update audit log entry scoped to the correct workspace.

Checklist

Required

• Filled out the "How to test" section in this PR
• Read Internal Workflow Guide
• Self-reviewed my own code
• Commented on my code in hard-to-understand areas
• Ran pnpm build
• Ran pnpm fmt
• Ran mise run fmt
• Checked for warnings, there are none
• Removed all console.logs
• Merged the latest changes from main onto my branch with git pull origin main
• My changes don't cause any responsiveness issues

Appreciated

• If a UI change was made: Added a screen recording or screenshots to this PR
• Updated the Unkey Docs if changes were necessary