fix(api): accept SetSecuritySettings on /v2/settings/security (#12518)

# Which Problems Are Solved

`GetSecuritySettings` is served at `GET /v2/settings/security`, but
`SetSecuritySettings` was only bound to `PUT /v2/policies/security`.
That split made the natural copy-paste path (`PUT
/v2/settings/security`)
return `405`, including the enable curl in the Dynamic Client
Registration
guide.

# How the Problems Are Solved

Make `PUT /v2/settings/security` the primary HTTP binding for
`SetSecuritySettings`, and keep `PUT /v2/policies/security` as an
`additional_bindings` entry so existing callers keep working.

# Additional Changes

None.

# Additional Context

- Noticed during review of the Dynamic Client Registration PR (#12313):
the
guide's enable curl used `PUT /v2/settings/security` and hit `405`
against a
  live instance.
- Only `settings/v2` is changed; `v2beta` is left as-is (deprecated).
- Generated gateway/OpenAPI artifacts are gitignored and rebuilt from
the
  proto on generate.

Co-authored-by: Cursor <cursoragent@cursor.com>

proto/zitadel/settings/v2/settings_service.proto

@@ -415,8 +415,12 @@ service SettingsService {
   //   - `iam.policy.write`
   rpc SetSecuritySettings(SetSecuritySettingsRequest) returns (SetSecuritySettingsResponse) {
     option (google.api.http) = {
-      put: "/v2/policies/security";
-      body: "*"
+      put: "/v2/settings/security";
+      body: "*";
+      additional_bindings {
+        put: "/v2/policies/security";
+        body: "*";
+      }
     };
 
     option (zitadel.protoc_gen_zitadel.v2.options) = {