Hotfix: make news audience migration non-atomic

[TThanos3000]

Summary

• Adds the production news.0010_news_audience_newscomment migration to dev with atomic = False.
• Keeps the migration business logic unchanged: existing news are still backfilled to platform, program news to program_participants, and the same news_valid_audience constraint / NewsComment schema are created.
• Adds matching News/NewsComment model schema so dev runtime stays consistent after applying the migration.
• Adds regression coverage for migration atomicity and a PostgreSQL-only migration replay scenario.

Why atomic = False

Django documents this PostgreSQL failure mode for migrations that combine schema changes and RunPython in the same transaction: PostgreSQL can raise cannot ALTER TABLE ... because it has pending trigger events. Setting migration-level atomic = False runs the migration operations outside one wrapping transaction. The RunPython operation does not pass atomic=True, so it does not reintroduce a transaction for this operation.

Production retry safety

The failed production run used the old atomic migration and should have rolled back the whole 0010 migration. Retrying with this changed migration should re-run AddField -> RunPython -> AddConstraint -> CreateModel without hitting pending trigger events.

Checks

• DEBUG=True python manage.py test news.tests.test_news_migration_0010 --verbosity=2 — passed; PostgreSQL-only regression skipped locally on sqlite.
• DEBUG=True python manage.py makemigrations --check --dry-run — passed, no changes detected.
• python -m flake8 news/models.py news/migrations/0010_news_audience_newscomment.py news/tests/test_news_migration_0010.py — passed.
• DEBUG=True python manage.py test news --verbosity=2 — passed: 28 tests OK, 1 PostgreSQL-only regression skipped locally on sqlite.

Not changed

• News attachment hotfix code.
• Workflows.
• Docker/nginx/Celery.
• Production/master branch.