Fix test datasource configuration and add GitHub Actions CI

[breckenedge]

Summary

Five things in this PR:

1. Fix tests/bootstrap.php so the test runner can actually load fixtures. The previous bootstrap aliased test → default, but CakePHP's FixtureManager::_aliasConnections() unconditionally calls alias('test', 'default') (the inverse direction) at line 124, overriding the bootstrap alias. After fixtures initialise, both names resolve to a test config that was never set up, so any test that touches a Table fails with:

   Cake\Datasource\Exception\MissingDatasourceConfigException: The datasource configuration "test" was not found.
   

   Replaced the alias with a real test Datasource registration that clones the default connection config and swaps the database name. Fixtures truncate tables, so they get a dedicated dms-calendar-test schema rather than touching dev data.

2. Make the PHPUnit suite actually discoverable. Two small things were preventing the suite from running:

   • phpunit.xml.dist pointed at ./tests/TestCase, which is empty — every test file in this repo lives under src/. Repointed the testsuite at ./src with a suffix="Test.php" glob, which picks up all 19 test classes.
   • Five test classes referenced a typo'd fixture, app.honorarias (the actual fixture class is HonorariaFixture, singular). That caused fixture init to throw and aborted those classes' runs. Renamed them to app.honoraria in CommitteesControllerTest, ContactsControllerTest, EventsControllerTest, HonorariaControllerTest, and EventsTableTest.

3. Add a GitHub Actions workflow (.github/workflows/test.yml) that spins up MariaDB 10.11 as a service container, installs PHP 7.4 + Composer deps, symlinks config/app.php to the default config (matching what the docker startup does), creates the test database, and runs the full PHPUnit suite on every push to master and on every PR.

4. Refuse to run tests against a non-local DB host. Per review feedback: if a developer's DATABASE_URL is misconfigured to point at the prod RDS instance, the bootstrap would derive dms-calendar-test from it and FixtureManager would happily TRUNCATE every table it manages against the prod host. The bootstrap now exits 1 with a clear error if the resolved default host isn't on a small allowlist (localhost, 127.0.0.1, ::1, db — the docker-compose service name). CI uses DB_HOST=127.0.0.1, which is covered. If a future use case legitimately needs another host, the allowlist is one line in tests/bootstrap.php.

5. Document the whole thing in docs/README.md (new ## Tests section): where tests live, the docker compose exec command to run them, how the test datasource is derived from default, the production guardrail, and a pointer to the CI workflow.

Setup note for local devs

After this PR, running tests locally requires the test database to exist on the same MariaDB server (CI handles this automatically):

CREATE DATABASE `dms-calendar-test`;
GRANT ALL PRIVILEGES ON `dms-calendar-test`.* TO 'calendar'@'%';
FLUSH PRIVILEGES;

Fixtures auto-create their own tables from each fixture's $fields definition, so no schema import is required.

What CI runs

The full suite — 100 test methods across all 19 test classes. Today most of them are still master's markTestIncomplete skeletons, but each class's setUp() exercises fixture init against the new test datasource, so any future regression in bootstrap/fixture wiring would fail CI immediately. Branches that add real tests on top of this inherit CI without any further setup.

[breckenedge]

Note that the updated specs passed on my own fork here: https://github.com/breckenedge/dallas-makerspace-calendar/actions/runs/25838167795/job/75917606374?pr=1

[mandarl]

@breckenedge - thanks for doing this!

• Looks good overall. Do you want to add a sections for Tests in ./docs/README.md?
• Q: is there a risk that if a developer is pointing to Production in DATABASE_URL (I would never do this 😂but ...) then the test fixtures might delete data in prod. Ideally we would have multiple guardrails to prevent this but I am thinking of worst case scenarios.

[breckenedge]

@breckenedge - thanks for doing this!

• Looks good overall. Do you want to add a sections for Tests in ./docs/README.md?
• Q: is there a risk that if a developer is pointing to Production in DATABASE_URL (I would never do this 😂but ...) then the test fixtures might delete data in prod. Ideally we would have multiple guardrails to prevent this but I am thinking of worst case scenarios.

Good call, I'll add a guardrail so that this can only run locally, and update docs/README.md describing the test suite.

[breckenedge]

@mandarl this good to go as is?