chore: untrack six committed .pyc files and ignore Python bytecode

Found while closing out the empty queue by running the four CI checks that had
not been run this session -- the checkers' own unit tests and the component
catalogue freshness check. All four pass (7, 15 and 45 tests, and "generated
component catalogue is current"), but running them left .pyc files that git
reported as untracked, which is how this surfaced.

Measured: SIX .pyc files were already tracked, ~143 KB in total, and .gitignore
covered neither __pycache__/ nor *.pyc. That contradicts CLAUDE.md's "Never
commit binaries".

Every one is a build artefact of a .py source that is present in the tree, and
they entered in two accidental commits from two different environments
(cpython-311 on 2026-07-30, cpython-313 on 2026-08-17) -- which is itself the
argument against tracking them: the same source produces a different file per
interpreter, so they can never be canonical.

Verified before removing: nothing in the repository references __pycache__ or a
.pyc, so no script depends on them. They are untracked with `git rm --cached`,
so the working copies stay on disk, and Python regenerates them anyway. After
the change all eight on-disk files are ignored, nothing is untracked, and
validate_module_boundaries, check_version_seam_odr and
generate_component_catalog --check all still pass.

No code changed; the gate is unaffected at 17,585.

Author: robertvokac

.gitignore

@@ -7,3 +7,10 @@ plan.sqlite3-journal
 plan.sqlite3-wal
 plan.sqlite3-shm
 docs/generated/
+
+# Python bytecode. These are build artefacts: regenerated automatically, specific to the
+# interpreter that produced them (cpython-311 vs cpython-313 both appeared here), and useless to
+# any other machine. Six of them had been committed accidentally -- see CLAUDE.md's "Never commit
+# binaries".
+__pycache__/
+*.pyc