ci: run the build-and-test workflow on master

[srpatcha]

ci.yml watched main and develop. Neither exists — this repository's default
branch is master:

default branch: master
main:           404 Branch not found

So every push to master and every pull request against it falls outside the
trigger, and the build-and-test workflow has not run on a change since
2026-05-31.

A repository-wide rename from main to master in late May left the workflow
pointing at a branch that had gone. The same thing happened in six repositories
at once:

repo	ci.yml watched	last run
eAI	[main, develop]	2026-05-31
eNI	[main, develop]	2026-05-31
eIPC	[main, develop]	2026-05-31
eDB	[main, develop]	2026-05-31
eBrowser	[main, develop]	2026-05-31
eOffice	[main, develop]	—

eApps is the one that got it right: [main, master, develop].

The change

master is added rather than substituted, on both push and
pull_request, so a rename in either direction does not break this again. YAML
validated.

Verified on eAI first

embeddedos-org/eAI#39 is the same change, and it demonstrably works — that PR
went from a single skipped assign job to C/C++ Tests and Python Tests
actually running.

Expect the first run to be red

Three months of changes have landed here with no build or test gate. Finding out
what broke is the point of turning it back on; it is not a regression introduced
by this PR.

Worth doing next

No repository in the organisation has a required status check
(required_status_checks: null everywhere). That gap let non-compiling code
reach master in eos and an unparseable file reach master in ebuild. Once this
workflow is green again, it is the obvious candidate to mark required.

This is the third hardcoded-name failure found this week, after
embeddedos-org/ebuild#81 ("branch": "main" for repositories whose default is
master) and embeddedos-org/EoSim#16 (a lowercase repo list that found 2 of 19
on a case-sensitive filesystem).

[srpatcha]

CI is running on this PR, and it immediately surfaced failures that have been
invisible since May. That is the point of the change, not a regression from it.

Same result across all six repositories where the trigger was orphaned:

repo	PR	pass	fail	first failure
eAI	#39	3	1	Python Tests
eNI	#30	7	1	Python Tests
eIPC	#31	6	1	Build & Test (Linux x86_64)
eDB	#70	5	3	Test (Python 3.10/3.11/3.12)
eBrowser	#20	3	3	Test (Python 3.10/3.11/3.12)
eOffice	#40	1	1	Lint & Type Check

Nine failing checks across six repositories, none of which anyone could see
yesterday. Most of the suites pass — the repositories are not broadly broken —
but each has at least one real problem that three months of merges walked past.

eAI's has been diagnosed (embeddedos-org/eAI#40): the test suite imports numpy,
which is declared nowhere, and ci.yml hides it with

pip install -r requirements.txt 2>/dev/null || true

where requirements.txt does not exist, so || true turns "nothing to install"
into a silent success. Worth checking whether the same line is in this
repository's workflow, since these files are near-identical across the
organisation — that one construct would also swallow a genuine pip failure.

On merging this while it is red

The red reflects reality; the green before it did not. My preference is to merge
the honest gate and fix what it finds, rather than hold the gate until the
repository is clean — the second option means the failures stay invisible for
however long that takes.

If you would rather land a green master, fix the failing check first and this
can follow. Either order works. What does not work is leaving the trigger
pointing at a branch that was deleted in May.