As a developer forking the template, I want a documented, disabled auth seam so that I know where to plug in authentication

[emaarco]

Why

The app has no auth — fine for a demo, but a greenfield proposal should show where security attaches instead of leaving a silent hole. CORS already ships as a disabled, documented escape hatch (DevCorsConfiguration, @Profile("dev")); auth deserves the same treatment: a visible, wired-but-inactive seam a forker flips on.

Goal

• Add a stubbed Spring Security config, inactive by default (profile-gated, analogous to DevCorsConfiguration), documenting where OAuth2 / resource-server config would go.
• Keep all endpoints open when the profile is off, so the demo is unchanged.
• Show the frontend side of the seam (where a token would attach in shared/api/http-client.ts) — documented, not implemented.
• Docs: a short note explaining the seam and how to activate it; consider an ADR if we decide the "seam, not implementation" stance is worth recording.

Acceptance

• Security config present but inactive by default; demo behaviour unchanged.
• The seam (backend + frontend) and how to enable it are documented.