Add CI that validates against real activity code

[dannystaple]

Problem

This repo has no tests (see #62/#63) — CI only lints (a single trailing-whitespace pre-commit hook) and checks that the package installs/builds. Since coder_dojo_common is really support glue for Coder Dojo activities (game programming, stats, maths visualisations), the most meaningful validation is running it against real activity code, not abstract unit tests.

Blocked by: #68 (need the list of activity sheets/repos before we know what to run in CI)

Goal

Once #68 has produced a reference list of activity sources, add a CI job that pulls in (or vendors copies of) representative activity code and runs it against the current coder_dojo_common, so breaking changes to the library get caught before they break a dojo session.

Approach (rough)

• Start small: pick one or two representative activities and get them running in CI as a smoke test
• Extend coverage incrementally per activity category, as sub-tickets:
  • Game programming activities (pgzero / games extra)
  • Stats/data activities (data extra: pandas, numpy, matplotlib, plotly)
  • Maths visualisation activities
  • Kenney asset CLI (kenney-assets command) — smoke test against a real asset pack
• Decide how activity code gets into CI: vendored copy in this repo vs. checkout of another repo vs. script fetched from Google Docs export
• Wire the smoke tests into on-pr-lint.yml (or a new workflow) so they run on every PR

This ticket is intentionally a placeholder/parent — split each checklist item into its own issue once #68 lands and it's clear what's actually available to test against.

[dannystaple]

Kenney asset CLI sub-ticket split out: #70 (doesn't need to wait on #68 since it's self-contained)

[dannystaple]

Note for the games/pgzero checklist item: running these headlessly in CI is well-trodden ground, not a stretch.

• Try `SDL_VIDEODRIVER=dummy` (env var) first — pygame/pgzero can initialize a display without any X server at all, which is enough for a smoke test that just checks the code imports/inits/runs a few frames without crashing.
• Fall back to `xvfb` (e.g. the `GabrielBB/xvfb-action` GitHub Action, or plain `xvfb-run`) only if the activity code needs an actual display — e.g. pixel/screenshot assertions.