Keep Linux and Windows workflows alive and fail regeneration on drift - #3

The Linux and Windows workflows each get a keepalive job (liskin/gh-workflow-keepalive@v1) that runs only on their weekly schedule and re-enables its own workflow. The regeneration steps now fail when regenerating changes the committed sources.

• a keepalive job in build_linux.yml and build_windows.yml with actions: write. The action re-enables only the workflow it runs in, so each scheduled workflow needs one of its own.
• keep_alive.yml removed: it only kept itself alive, and no other scheduled workflow is left that needs it
• both (sources regeneration) build steps end with git add --intent-to-add --all -- <gen dir> + git diff --exit-code -- <gen dir>, for src and pmr/src. New files count as drift too.
• CMakeLists.txt and pmr/CMakeLists.txt pass -ignoreTimestamps to zserio. Without it, zserio skips output files that are newer than tutorial.zs, so the check passed without regenerating anything.

Verified:

• "regeneration fails on a non-empty git diff": ran the regeneration locally for . and pmr (latest zserio release); cmake exit 0 every time. On the committed sources the check exits 0. With an extra line committed in src/tutorial/Employee.h and pmr/src/tutorial/Employee.h, regeneration removes it and the check exits 1 for each. Before -ignoreTimestamps, that same committed edit gave exit 0.
• local build of the tutorial plus write_joe/read/write_boss/read → build exit 0, run exit 0
• PR CI on the head commit: build_linux pass (1m0s), build_windows pass (2m31s) at 55f6890, including the new diff check on both; both keepalive jobs skipped as intended on pull_request
• actionlint on both workflows → exit 1, 10 findings. All are in lines that already existed (checkout@v3, setup-java@v3, setup-python@v4, SC2035 on rm -rd *), none in the lines added here.
• 5 files changed, 30 insertions(+), 16 deletions(-)

Not verified: the keepalive job itself. It runs only on schedule, so the first real run is the next Sunday cron.

Closes #2