Let demo, local, and test run only alone and guard every profile against the demo users (B06)

[AsyncAssassin]

Summary

B06 from the merged review of v0.4.0 (prod,demo bypassed the demo-user guard); 0.4.1 is released once all fixes are merged. A regression review of the first version showed that the guard only knew the literal prod, so this PR closes the whole class:

• demo, local, and test run only alone: SPRING_PROFILES_ACTIVE=prod,demo on a fresh database let the demo seeder write demo-operator after the guard had checked, and staging,demo or staging,local had the same gap without any guard. ProfileCombinationGuard, an environment post-processor registered in META-INF/spring.factories, now refuses any of these three next to another profile before the application context exists, and before a placeholder of the other profiles is resolved, so prod,local without the prod secrets names the combination instead of failing on ASSET_SYNC_DB_URL. The demo-only beans keep plain @Profile("demo"); this guard is the single point that keeps them out of other profiles.
• Every profile with authentication except demo refuses the demo users: ProdDemoUserGuard ran only under prod. It now runs in prod, e2e, a custom profile such as staging, and a start without any profile. It is @Lazy(false), so spring.main.lazy-initialization cannot skip it. It lets a database without the users table start instead of failing on its own query. Its message names the default profile when none is active and recommends an empty database, because a database the demo ran on also holds the demo dataset.
• The prod operator account cannot take a demo user name: the next start would have refused its own admin.

CHANGELOG.md lists both under [Unreleased] → Security.

Verification

• ./gradlew clean check: 280 tests, 0 failures, 2 skipped (the env-gated Alchemy live smoke).
• ProfileCombinationGuardTests pins the profile matrix. It covers which sets start, which are refused, and that the demo-user guard runs in exactly the sets that may start, except demo.
• ProdProfileBootIntegrationTests boots second contexts against the test container:
  • prod,demo, prod,local, prod,test, staging,demo, and staging,local are refused with their exact profiles, against a separate empty database that must stay empty;
  • prod,local without the prod secrets is refused;
  • prod, staging, and no profile refuse the demo users;
  • staging starts on a database without the users table;
  • an admin named demo-operator fails.
• Mutation check: without the spring.factories registration, prod,demo starts and the no-secrets case fails on a placeholder, so both tests go red.
• The first version of this PR was also verified live: prod,demo and prod,local stop before migrations, and staging and prod refuse a database a demo start seeded.

This PR and #15 both add a section under [Unreleased] in CHANGELOG.md, so whichever merges second needs a one-file rebase. The other files merge cleanly with #15.

[AsyncAssassin]

Combined into #23 together with the other batch-1 fixes, so they merge without a rebase per PR. This description keeps the detailed evidence for its fix.