fix(tests): cotton integration tier exercises real compilation (#79)

[fsecada01]

Summary

• tests/integration/cotton_app/settings.py never listed django_cotton in INSTALLED_APPS, so its AppConfig.ready() never ran and Django's template engine treated <c-cf.*> tags as inert literal text — test_cotton_integration.py's assertions were satisfied by uncompiled markup, not real cotton output.
• Added django_cotton to INSTALLED_APPS and COTTON_SNAKE_CASED_NAMES = False (matching the precedent already set in tests/e2e/_e2e_django_settings.py), and added a regression assertion to each of the three existing tests proving the raw <c-cf.*> tag is compiled away, not passed through.
• Registering django_cotton surfaced a bigger, previously-latent problem: django_cotton.apps.LoaderAppConfig.ready() mutates settings.TEMPLATES in place and resets Django's global template-engine cache — a permanent, process-wide side effect the moment it's in INSTALLED_APPS. justfile's test-all recipe ran tests/unit and tests/integration in one pytest tests/ process, so once cotton was registered its loader/builtins leaked into every unit test's render_to_string call, breaking ~400 unrelated unit tests.
• .github/workflows/ci.yml was never affected — it already runs each tier as its own step (separate process) — but test-all needed the same separation to match. Fixed test-all to invoke pytest once per tier, and corrected tests/integration/conftest.py's docstring, which had documented a conftest "race" that doesn't actually matter once tiers never share a process.

Test plan

• pytest tests/integration/test_cotton_integration.py -v — all 3 tests pass against real compiled markup (confirmed the new assert b"<c-cf..." not in r.content assertions fail without the INSTALLED_APPS fix, pass with it)
• pytest tests/unit -q — 2826 passed, 13 skipped, run alone
• pytest tests/integration -q — 25 passed, run alone
• ruff check src tests / ruff format --check src tests — clean
• Confirmed via debug instrumentation that the previous conftest docstring's claimed configure-order was empirically false, and that the real fix is process separation (matching CI), not fixing the race

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ur2c6d3peuerUGgRdJ6Fvs

[fsecada01]

/review findings

4 findings surfaced, 2 verified via direct reproduction:

1. [Fixed in 9f37bac] The "tiers must never share a process" invariant was only convention (justfile/CI recipe discipline), not enforced in code. A bare pytest invocation — the literal default under pyproject.toml's testpaths = ["tests"] — still collected tests/unit and tests/integration into one process and reintroduced the exact settings.TEMPLATES leak this PR fixes, reproducing as 415 failed / 2660 passed. Added a pytest_collection_modifyitems guard in tests/integration/conftest.py that raises a clear pytest.UsageError if both tiers get collected together, instead of letting it silently produce hundreds of confusing failures. Verified: bare pytest now fails fast with the explanatory error; both tiers still pass individually.

2. Not fixed — accepted as existing convention. just test-all's new 3-line recipe stops at the first failing tier (confirmed empirically: just aborts a recipe on the first non-zero exit line) rather than reporting all tiers' failures like the old single pytest tests/ invocation did. This matches the repo's existing check: lint lint-templates test recipe, which has the same stop-at-first-failure behavior today — not a novel regression, just extending an already-established local-dev tradeoff. CI is unaffected either way (it never calls test-all; it runs each tier as its own workflow step).

3. [Fixed in 9f37bac] CLAUDE.md's Testing Strategy section claimed "Only E2E actually exercises <c-vars> compilation" — stale as of this PR, since the integration tier now does too. Corrected.

4. Not fixed — accepted as minor duplication. INSTALLED_APPS/COTTON_SNAKE_CASED_NAMES/comment block is now duplicated near-verbatim between tests/integration/cotton_app/settings.py and tests/e2e/_e2e_django_settings.py. Real, but a 3-line duplication between two settings files scoped to their own tiers doesn't justify a shared-base abstraction for two call sites.

All gates re-verified after the fixes: pytest tests/unit (2826 passed, 13 skipped), pytest tests/integration (25 passed), bare pytest now fails fast with the guard's message, ruff check/ruff format --check clean.