While you're probably correct about the move from SourceForge to Trac, there's definitely not something like that going on in the current proposal: you use TRAMP to build your static assets and you will keep doing that, even after deployment moves to GitLab. GitLab Pages is - from a user perspective - nothing more than a pipeline which specifies where the generated output is.
TRAMP is not a static site generator, it is an Emacs virtual file system for editing files and running commands remotely, that works over SSH. I do not use a site generator for c-l.net projects.
That pipeline/CI job builds your static content using your own preferred static site generator (in case of c-l.net, that's some amalgamation of cl-markdown, plump, cl-who, etc. and in your case that's TRAMP). Building in this context can be as simple as "take the pre-built pages stored in a Git repository and declare those to be the build output". The additional bit that Pages does is to take the output from a CI build and deploy it on the Pages host. This last step simply means the pages become available as https://common-lisp.net/project/<some-project>/...
My concern is that this requires you to use git, and then requires you to use Gitlab (and it sounds like you also need to configure Gitlab Pages to know about files in your git repository), all so that Gitlab can copy some files to https://common-lisp.net/project/<some-project>/. That is a lot of dependencies if you only want to copy some files. As you have encountered already, this approach has problems. It is a nice option, but I do not think it should be the only option.
Vladimir