Brand Customization Release Notes - 2026-05-08

This note covers the operator-visible behavior changes shipped with the brand-scoped customization rollout for servers_v2.

Required Operator Checks

Public content is now brand-scoped at runtime. Reads for notices, user notices, banners, promotions, and promotion events filter by the request brand. Existing rows must have the intended brand_id; one content row no longer automatically appears for every brand.
New brands need their own public content rows before traffic is routed to them. The historical backfill covers existing rows, but it does not create default announcements, banners, or promotions for future brands.
Provider visibility is brand-scoped through brand_provider_config. The first single-provider PATCH on a brand with no provider rows materializes the current globally visible provider snapshot, so later provider additions are not inherited by that brand until the brand policy is cleared or replaced.

site_setting still returns the legacy flat fields, but it also includes the nested public brand config objects: brand, frontend_config, registration_policy, feature_policy, payment_policy, and sms_policy. Strict clients and generated DTOs need to allow these additional fields.
POST /deposit/gate/support and POST /deposit/coin/support now require X-Brand-Id. Direct internal health checks or scripts that called these routes without a brand header must be updated.
POST /deposit/gate/create and POST /deposit/coin/create now validate the requested amount against the effective brand deposit min/max range. Requests that previously created an order with an out-of-range amount now return Invalid deposit amount.

feature_policy.*_enabled is the maintenance or emergency kill-switch layer. Product/channel objects such as registration_policy and payment_policy are the normal operating policy layer. Runtime enablement is an AND across the relevant layers, so a feature only opens when both layers allow it.
For finance limits and Plisio settings, the payment_policy object wins over legacy scalar compatibility keys. New server-config exports should emit the policy object only.
payment_policy.deposit_maintenance_enabled and maintenance time fields are tri-state. Omitted/null values fall back to legacy global_var; false or an empty string is an explicit brand override.

Runtime brand config readers currently read PostgreSQL directly. This is acceptable for the rollout, but high-RPS paths such as login and game launch can add a short Redis cache with explicit invalidation if DB load becomes visible.
The dual-layer policy model is intentional for this release, but admin UI should label feature_policy as an emergency/maintenance layer so operators do not confuse it with product-channel switches.