Settings: one tenant settings document with module-declared sections, host default and tenant override

Settings a client would expect to own are per deployment. `SystemSetting` and `EmailSettings` are single tenanted (`barakoCMS/Extensions/ServiceCollectionExtensions.cs:530-531`, `:621-622`). Analytics (`BarakoCMS.Analytics.Umami/UmamiOptions.cs`), S3 storage (`BarakoCMS.Files.S3/S3StorageOptions.cs`) and external sign-in providers (`BarakoCMS.ExternalAuth/ExternalAuthSupport.cs`) come from host configuration. Each new per-tenant need grows its own store: #854 auth per tenant, #781 storage per site, and barakoPress plugins per tenant.

### Why it matters

Two clients on one API cannot send mail from their own domains, use different analytics sites or different buckets. A school and a clinic on the same box share one mail provider and one sender. Every module that wants a tenant setting invents its own document and its own override rule.

### The general concept

One tenant settings document with sections that modules declare, each key resolving tenant override first, then host default. Secrets in it are write-only and stored the way `ConnectorSecret` stores them. This extends #890, which gives modules declared keys and categories; this issue is the tenant scope over those keys.

Part of the decision on the tenant as the unit of operation, linked from the umbrella issue.

### Where it lives

Core: settings, with sections declared by modules (Email, Files.S3, Analytics.Umami, ExternalAuth).

### Compatibility

Released. Existing `SystemSetting` and `EmailSettings` rows become the host default, so nothing changes for a deployment that sets no tenant override. Host configuration keys keep working as defaults. The settings endpoints gain an optional tenant scope, which is additive.

### Done when

- A tenant override for the mail sender is used for that tenant's mail while another tenant keeps the host default, and a test showing that fails before the change.
- A module declares a section and reads its keys through the same resolver.
- Secret values in tenant settings are never returned on read.

Found in the architecture sweep of 15 September 2026.

Start by reading the existing registrations in barakoCMS/Extensions/ServiceCollectionExtensions.cs and the module option definitions in BarakoCMS.Analytics.Umami/UmamiOptions.cs, BarakoCMS.Files.S3/S3StorageOptions.cs, and BarakoCMS.ExternalAuth/ExternalAuthSupport.cs. Review issue #890 for the declared-key model. Done means tenant-specific mail behavior is covered by a failing-before test, modules use the shared resolver, and tenant secrets are never returned.

Written by the indexing model from the issue text.