R-follow-up — Admin-configurable PlatformReservedPriority (today hardcoded at 9000)

[haydercyber]

Parked follow-up to EPIC R (#108). NOT a v1 blocker.

Context

EPIC R §1 sign-off hardcoded `const PlatformReservedPriority = 9000` for v1. Per §1 lock: "Do not make this admin-configurable in v1. Hardcoded is safer and simpler."

This issue tracks revisiting the choice when operational evidence calls for it.

When to revisit

• A deployment legitimately needs more priority headroom for scoped authors (e.g. they want 4 priority bands within their projects, and 9000 is too low a ceiling)
• A deployment has overlapping platform policy authors who want sub-banding within platform's reserved range
• A managed-SaaS posture where different tenants want different bands

Proposed direction (if pursued)

Add a settings table entry:

```
secrets_bridge_settings
key value
platform_reserved_priority 9000
```

Service reads via `SettingsRepository.GetInt("platform_reserved_priority", 9000)`. SPA admin page exposes a single-field editor under a "Platform configuration" section gated by `settings.edit` (new permission — or extend an existing `platform.config` perm if one lands first).

Migration carries forward the existing 9000 value; no behavior change on upgrade.

NOT in scope

Filing as a tracking issue. No implementation work until real demand materializes.