fix(controller): super.config() in chapter 6 + generator templates so CSRF inherits (F10)

[bpamiri]

Summary

F10 from the 2026-05-01 afternoon fresh-VM run. Originally hypothesised as a "CSRF flag never set in production" framework bug needing a new middleware; actually a chapter-6 paste-bug + generator-template defensiveness gap. The framework's CSRF wiring is intact — what was missing was `super.config()` calls in places where users override `config()`.

Investigation that overturned the original diagnosis

Initial grep for `request.$wheelsProtectedFromForgery` only found assignments in test fixtures. Conclusion: "the flag is never set in production." Wrong.

Closer reading: `vendor/wheels/controller/csrf.cfc` defines `$flagRequestAsProtected()` which DOES set the flag, called from `$runCsrfProtection(action)` which DOES run on every action via `vendor/wheels/controller/processing.cfc:12`. The chain only fires when `variables.$class.csrf` is set, which only happens when the controller called `protectsFromForgery()` in `config()`.

The generated `app/controllers/Controller.cfc` (project base, written by `wheels new`) calls `protectsFromForgery()` in its `config()`. So new apps DO get protection — IF child controllers call `super.config()`.

The fresh-VM observation matches this exactly:

Controller	`config()` override	`super.config()` called	Form has token
Chapter 6 `Sessions.cfc`	none	n/a (inherits)	✓
Chapter 6 `Users.cfc`	none	n/a (inherits)	✓
Chapter 6 `Posts.cfc` (6a)	yes (adds `filters`)	no	✗
Chapter 6 `Posts.cfc` (6b)	yes (adds `filters`)	no	✗

Same code pasted twice in chapter 6 was the root cause. The signup/login forms had tokens because their controllers don't override `config()` at all. The post-create form didn't have a token because chapter 6's `Posts.cfc` paste broke the inheritance chain.

Fixes

Chapter 6 paste-bugs

Both `Posts.cfc` instances now call `super.config();` as the first line of `config()`. Plus a new `

` callout right after the controller walkthrough explaining the failure mode:

The first line of `config()` is `super.config();`. If you skip it, you silently disable everything `app/controllers/Controller.cfc` does in its `config()` — most importantly, `protectsFromForgery()` …

Generator templates

Four templates that were prone to the same trap now call `super.config()` with explanatory comments:

• `cli/src/templates/ControllerContent.txt` (legacy CommandBox)
• `cli/lucli/templates/app/app/snippets/ControllerContent.txt` (LuCLI app template)
• `cli/lucli/templates/snippets/crud-controller.txt` (CRUD snippet)
• `cli/lucli/templates/snippets/auth-sessions-controller.txt` (auth snippet)

The fifth template, `cli/lucli/templates/snippets/api-controller.txt`, is the deliberate exception. APIs usually authenticate via API keys / bearer tokens, not session cookies, so the session-CSRF check doesn't apply. Updated to call `protectsFromForgery(with="ignore")` explicitly so the opt-out is intentional rather than accidental.

What this PR doesn't do

• No framework code change. The infrastructure is correct; the bug was upstream of it.
• No new middleware. My initial proposal involved a `Csrf` middleware that would have duplicated the existing controller-layer logic. Not needed.
• No global default flip. I considered adding `application.wheels.csrfProtection = true` as a framework-level setting that would force protection even when controllers forget `super.config()`. Decided against it for this PR — would require updating ~10 framework test fixtures (every `vendor/wheels/tests/_assets/controllers/*.cfc` that doesn't already call `protectsFromForgery`) since they'd suddenly start rejecting POSTs with no token. That's a separate larger PR if the team wants belt-and-braces protection against the super.config() footgun.

Tests

Doc/template-only changes, no framework code touched.

• Full SQLite suite: 3377 passed, 0 failed (same baseline as #2403)
• The chapter 6 `{test:compile}` doctest annotation will validate that the new `super.config();` line compiles in CI.

Memory note

The `project_csrf_never_enforced.md` memory entry has been corrected. The original misdiagnosis is preserved in the entry as a "lesson learned" anchor — a good example of why grep-based "never assigned" conclusions need a second pass for indirect setters.

🤖 Generated with Claude Code