chore(docs): update of OEL changelog

docs/self-hosted/oel/keto/changelog/v26.2.5.md

@@ -0,0 +1,35 @@
+## v26.2.5
+
+### Limit tree size in expand endpoint (default 4k nodes)
+
+The expand endpoint now returns a maximum of 4,000 nodes by default to reduce backend resource usage. For OSS and OEL deployments,
+this limit can be configured via `limit.max_expand_size` config.
+
+### Fix shared mutable state in error handling
+
+Error globals such as `herodot.ErrNotFound` were package-level variables shared across all requests. Calling methods like
+`WithReason` or `WithDetail` mutated these variables in place and returned the same pointer, so any request that added context to
+an error — reason text, details, etc, modified the global. The next request to reach an error path using the same error inherited
+those stale details.
+
+As a consequence, observability (logs, traces) for requests resulting in an error suffered from the same issue: some errors were
+reported with details belonging to an unrelated request, or with fields missing that should have been present.
+
+The new API creates a fresh error instance on each call, so each request gets its own copy.
+
+The following values were at risk of leaking into unrelated error responses:
+
+- HTTP cookie names (Kratos CSRF flow)
+- Entity UUIDs (identity, organization, etc)
+- OAuth2 error hints (Hydra and Kratos Hydra bridge)
+- OIDC provider URLs and raw upstream error responses (Kratos OIDC strategy)
+- External schema fetch URLs and HTTP status codes (Kratos schema handler)
+- JWT claims and issuers (Oathkeeper JWT authenticator)
+
+No data was written to persistent storage or transmitted outside the error response. Any two requests hitting the same error path
+on the same node — even back-to-back with no concurrency — could exchange error details.
+
+Under concurrent load, the shared writes also constitute a true data race, which can additionally produce errors in an
+inconsistent or partially written state.
+
+This change has no externally observable effect other than fixing the information leak in error paths.

docs/self-hosted/oel/kratos/changelog/v26.2.5.md

@@ -0,0 +1,59 @@
+## v26.2.5
+
+### Fix shared mutable state in error handling
+
+Error globals such as `herodot.ErrNotFound` were package-level variables shared across all requests. Calling methods like
+`WithReason` or `WithDetail` mutated these variables in place and returned the same pointer, so any request that added context to
+an error — reason text, details, etc, modified the global. The next request to reach an error path using the same error inherited
+those stale details.
+
+As a consequence, observability (logs, traces) for requests resulting in an error suffered from the same issue: some errors were
+reported with details belonging to an unrelated request, or with fields missing that should have been present.
+
+The new API creates a fresh error instance on each call, so each request gets its own copy.
+
+The following values were at risk of leaking into unrelated error responses:
+
+- HTTP cookie names (Kratos CSRF flow)
+- Entity UUIDs (identity, organization, etc)
+- OAuth2 error hints (Hydra and Kratos Hydra bridge)
+- OIDC provider URLs and raw upstream error responses (Kratos OIDC strategy)
+- External schema fetch URLs and HTTP status codes (Kratos schema handler)
+- JWT claims and issuers (Oathkeeper JWT authenticator)
+
+No data was written to persistent storage or transmitted outside the error response. Any two requests hitting the same error path
+on the same node — even back-to-back with no concurrency — could exchange error details.
+
+Under concurrent load, the shared writes also constitute a true data race, which can additionally produce errors in an
+inconsistent or partially written state.
+
+This change has no externally observable effect other than fixing the information leak in error paths.
+
+### Native OIDC registration now returns the flow ID when required traits are missing
+
+When a native or API-based OIDC registration flow encounters a validation error because of missing required identity traits, the
+`return_to` redirect now includes the `flow` query parameter alongside the existing `code` parameter.
+
+This allows native clients to fetch the registration flow, identify which fields are missing, and re-submit with complete data.
+Previously, only the `code` parameter was included, leaving native clients with no way to recover from missing traits during
+social sign-in registration.
+
+Browser flows were not affected by this issue.
+
+### Phone numbers are now normalized to E.164 format
+
+Kratos now normalizes phone numbers to E.164 format when used as identifiers, verifiable addresses, or recovery addresses. This
+ensures consistent storage and lookup regardless of how a user enters their phone number (with spaces, dashes, or parentheses).
+
+Existing identities with non-normalized phone numbers continue to work. A new CLI command `kratos migrate normalize-phone-numbers`
+is available to normalize legacy phone data in the database. Run this command after deploying the update to ensure all phone
+numbers are in E.164 format.
+
+### Render identity schema `enum` traits as dropdowns
+
+Identity schema properties that declare an `enum` are now surfaced to the Account Experience and rendered as native `<select>`
+inputs, so users can pick from the allowed values instead of typing them into a free-form text box.
+
+Kratos attaches the enum values to the UI node as an `options` array on `InputAttributes`. When present, the Account Experience
+falls back to rendering the field as a dropdown; consumers that do not know about `options` continue to render a text input as
+before, so the change is backward compatible.

docs/self-hosted/oel/oathkeeper/changelog/v26.2.5.md

@@ -0,0 +1,30 @@
+## v26.2.5
+
+### Fix shared mutable state in error handling
+
+Error globals such as `herodot.ErrNotFound` were package-level variables shared across all requests. Calling methods like
+`WithReason` or `WithDetail` mutated these variables in place and returned the same pointer, so any request that added context to
+an error — reason text, details, etc, modified the global. The next request to reach an error path using the same error inherited
+those stale details.
+
+As a consequence, observability (logs, traces) for requests resulting in an error suffered from the same issue: some errors were
+reported with details belonging to an unrelated request, or with fields missing that should have been present.
+
+The new API creates a fresh error instance on each call, so each request gets its own copy.
+
+The following values were at risk of leaking into unrelated error responses:
+
+- HTTP cookie names (Kratos CSRF flow)
+- Entity UUIDs (identity, organization, etc)
+- OAuth2 error hints (Hydra and Kratos Hydra bridge)
+- OIDC provider URLs and raw upstream error responses (Kratos OIDC strategy)
+- External schema fetch URLs and HTTP status codes (Kratos schema handler)
+- JWT claims and issuers (Oathkeeper JWT authenticator)
+
+No data was written to persistent storage or transmitted outside the error response. Any two requests hitting the same error path
+on the same node — even back-to-back with no concurrency — could exchange error details.
+
+Under concurrent load, the shared writes also constitute a true data race, which can additionally produce errors in an
+inconsistent or partially written state.
+
+This change has no externally observable effect other than fixing the information leak in error paths.

docs/self-hosted/oel/oauth2/changelog/v26.2.5.md

@@ -0,0 +1,30 @@
+## v26.2.5
+
+### Fix shared mutable state in error handling
+
+Error globals such as `herodot.ErrNotFound` were package-level variables shared across all requests. Calling methods like
+`WithReason` or `WithDetail` mutated these variables in place and returned the same pointer, so any request that added context to
+an error — reason text, details, etc, modified the global. The next request to reach an error path using the same error inherited
+those stale details.
+
+As a consequence, observability (logs, traces) for requests resulting in an error suffered from the same issue: some errors were
+reported with details belonging to an unrelated request, or with fields missing that should have been present.
+
+The new API creates a fresh error instance on each call, so each request gets its own copy.
+
+The following values were at risk of leaking into unrelated error responses:
+
+- HTTP cookie names (Kratos CSRF flow)
+- Entity UUIDs (identity, organization, etc)
+- OAuth2 error hints (Hydra and Kratos Hydra bridge)
+- OIDC provider URLs and raw upstream error responses (Kratos OIDC strategy)
+- External schema fetch URLs and HTTP status codes (Kratos schema handler)
+- JWT claims and issuers (Oathkeeper JWT authenticator)
+
+No data was written to persistent storage or transmitted outside the error response. Any two requests hitting the same error path
+on the same node — even back-to-back with no concurrency — could exchange error details.
+
+Under concurrent load, the shared writes also constitute a true data race, which can additionally produce errors in an
+inconsistent or partially written state.
+
+This change has no externally observable effect other than fixing the information leak in error paths.

docs/self-hosted/oel/polis/changelog/v26.2.5.md

@@ -0,0 +1 @@
+No changelog entries found for polis/oel in versions v26.2.5