refactor(runner): link runner bits instead of copying them

[RedBoardDev]

Constat

Préparer un runner recopie l'intégralité de la release en cache dans son workdir. Mesuré sur l'hôte KARE :

runner installe (hors _work)   675 Mo
runners provisionnes / 24h     343
                             = 231 Go ecrits puis effaces chaque jour

pidstat sur cet hôte classe ghr premier écrivain disque de la machine, à 132 Mo/s en rafale, devant les Runner.Worker eux-mêmes. Pendant ces rafales la latence disque passe de 0,58 ms à 75,83 ms avec une file de 553 requêtes, ce qui fait déraper les steps Initialize containers et Stop containers des jobs (20 s → 1m43, 7 s → 1m51 sur un run mesuré).

Or ces fichiers sont en lecture seule pendant toute la vie du job : le runner écrit dans _work, _diag et les fichiers de configuration qu'il crée lui-même, jamais dans ses propres binaires. Le runner est lancé en JIT éphémère (ACTIONS_RUNNER_INPUT_JITCONFIG), donc il ne se met pas à jour lui-même non plus.

Changement

copyFile tente os.Link et retombe sur la copie octet par octet si le lien est refusé (autre système de fichiers, limite de liens). Le comportement est donc inchangé partout où le lien est impossible. Les répertoires et les liens symboliques gardent leur traitement existant, y compris les gardes contre les symlinks absolus ou qui s'échappent.

Tests

Deux tests ajoutés : l'un vérifie que les fichiers réguliers sont bien liés (os.SameFile), l'autre que le repli en copie produit un fichier indépendant quand os.Link échoue. Les 362 tests du dépôt passent, gofmt et go vet sont propres.

Risque à connaître

Les fichiers du workdir partagent désormais leur inode avec le cache. Si un jour quelque chose écrit en place dans un fichier du runner, la modification atteindrait le cache partagé et casserait tous les runners provisionnés ensuite. Le commentaire dans le code nomme ce piège.