fix: remove dangling symlink from gh-pages to fix Pages build

[Copilot]

The pages-build-deployment "build" job fails because app/api/exercises exists in the gh-pages branch as a symlink to ../../exercises, but that target doesn't exist in gh-pages. Jekyll always runs on Pages source content and crashes when it can't resolve the symlink target.

Changes

• .github/workflows/fix-gh-pages.yml — new workflow that checks out gh-pages, detects all dangling symlinks via find . -xtype l, removes them with git rm, and pushes the fix back. Runs on every push to main and supports workflow_dispatch for immediate manual triggering.

[shramee]

I think it'd be better to check why these extra files are getting committed in the first place.

[Copilot]

I think it'd be better to check why these extra files are getting committed in the first place.

The root cause is that app/api/exercises and app/api/info.toml are runtime convenience symlinks (pointing to ../../exercises and ../../info.toml) that were committed to git. When the gh-pages branch was populated, they were carried over, but since exercises/ and info.toml don't exist at the root of gh-pages, they dangle and crash Jekyll.

Fixed in the latest commit by untracking both symlinks from git and adding them to app/api/.gitignore. Also removed the reactive cleanup workflow since it was treating the symptom rather than the cause.