Upgrade starter kit to Wagtail 7.3 version

[DaisyZhang77]

Closes #89

Summary

• Upgrade Wagtail from 6.4 to 7.3 in requirements.txt.
• Change Django range to >=4.2,<6.1, matching Wagtail 7.3’s supported versions.
• Keep and validate existing dependencies (psycopg[binary], whitenoise, django-storages[s3], wagtail-storages, gunicorn>=23.0.0).
• Update settings docstrings and comments to point at the stable Django docs (/en/stable/).
• Add a make test target and a “Testing” section in the README so users can easily run manage.py check + tests.
• Ensure the starter kit’s search view tests run against the upgraded stack (and document the known Django test-client issue on Python 3.14).

Testing

On Python 3.13:

• pip install -r requirements.txt
• python manage.py check
• make test
• make load-data then make start
• Manually visited / and /admin and confirmed pages and admin load correctly.

AI usage

None

[AviraL0013]

Tested this locally on Windows 11 with Python 3.11. Overall the upgrade works well! Here are a few observations from a fresh install perspective:

✅ What works perfectly:

• No more dependency downgrades: Wagtail stays at 7.3.1 and Django at 5.2.12.
• Zero dependency conflict errors during pip install.
• make test runs and passes successfully.
• The site and admin dashboard load correctly right out of the box.

⚠️ Minor rough edge on setup (make load-data):
Running make load-data produces a wall of ~25 tracebacks from modelsearch.tasks.insert_or_update_object_task (e.g., ArticlePage matching query does not exist).

It looks like the immediate task backend is trying to index objects during fixture loading before the references are fully resolved in the database.

Note on testing: Despite the tracebacks during setup, the search functionality does still work properly (e.g., searching for "mackerel" correctly returns 1 result), and the data loads fine. It's not a functional blocker, but it might look a bit scary to a newcomer trying Wagtail for the first time.