fix(technos): séparer le contenu Spring Boot 4 du socle base spring-boot.md

En tant que développeur utilisant shared-guidelines pour bootstrapper un projet
Je veux que spring-boot.md (base) ne contienne que des conventions indépendantes de la version, et que spring-boot-4.md contienne les spécificités de Spring Boot 4
Afin de disposer d'un guideline Spring Boot 4 complet, sans doublon, structuré en base + delta comme le reste du registre (java, react)

Contexte

Le registre guidelines/technos/techs.yaml déclare la techno spring-boot avec une version 4 :

spring-boot:
  description: "Spring Boot framework guidelines"
  base: spring-boot.md
  versions:
    - 4
  latest: 4
  versionFiles:
    4: spring-boot-4.md

Le mécanisme d'installation (resolveInheritanceChain() + concatenateFiles() dans scripts/install-guidelines.js) concatène systématiquement base + fichier de version, sans aucune déduplication. Tout ce qui se retrouve dans les deux fichiers sera dupliqué tel quel dans le guideline généré.

Problème

Contrairement à java.md (base explicitement version-agnostique : "indépendamment de la version… socle commun applicable à Java 17, 21, 25") complété par les deltas java-21.md / java-25.md, le fichier guidelines/technos/spring-boot.md actuel est déjà entièrement rédigé comme un guideline Spring Boot 4 :

• Titre : "Guidelines Spring Boot 4"
• "Spring Boot 4 = Spring Framework 7 + Jakarta EE 11", namespace jakarta.* (vs javax.*)
• ProblemDetail (RFC 7807) présenté comme "supporté nativement par Spring Boot 4"
• SecurityFilterChain documenté avec suppression explicite de WebSecurityConfigurerAdapter
• Virtual Threads "gérés automatiquement" par Spring Boot 4

Il n'existe donc aucune séparation base/version pour Spring Boot : la base contient déjà 100 % du contenu v4. Créer spring-boot-4.md sans retravailler spring-boot.md produirait, une fois concaténé, soit un fichier vide de sens, soit un doublon pur du contenu déjà présent dans la base.

Le travail réel n'est donc pas d'ajouter un fichier isolé, mais de scinder le contenu existant :

1. Extraire de spring-boot.md tout ce qui est spécifique à la version 4 (les points listés ci-dessus, et toute section qui décrit un comportement/API propre à Spring Boot 4 plutôt qu'une convention d'équipe intemporelle).
2. Réécrire spring-boot.md pour qu'il ne contienne que des conventions génériques applicables à tout projet Spring Boot (architecture en couches, DTOs, transactions, logging, MapStruct, interdictions…), sans référence à une version précise — sur le modèle de java.md.
3. Créer spring-boot-4.md avec le contenu extrait à l'étape 1, complété si besoin des autres nouveautés/breaking changes de Spring Boot 4 pertinents et non encore documentés.

Critères d'acceptation

• Étant donné spring-boot.md, quand on le relit, alors il ne contient plus aucune référence explicite à la version 4 (titre, Jakarta EE 11, "nativement supporté par Spring Boot 4", etc.) et reste valable pour toute version raisonnable de Spring Boot.
• Étant donné spring-boot-4.md créé, quand on compare son contenu à celui de spring-boot.md, alors aucune règle n'est dupliquée entre les deux fichiers (le mécanisme de concaténation ne dédoublonne rien — la non-duplication doit être garantie à la rédaction).
• Étant donné la sélection --techs spring-boot@4, quand on exécute l'installation, alors le guideline généré (base + version) est complet et cohérent : conventions génériques + spécificités v4 (Spring Framework 7, Jakarta EE 11, ProblemDetail natif, SecurityFilterChain, Virtual Threads, etc.), sans rien perdre du contenu actuel.
• Étant donné node scripts/check-structure.js, quand on le lance après ces changements, alors la validation passe sans erreur.
• Étant donné la structure des autres couples base/version existants (java.md/java-21.md, react.md/react-19.md), quand on compare spring-boot.md/spring-boot-4.md, alors elle suit le même modèle (base = intemporel, version = delta daté).

Dépendances

• Aucune dépendance externe.
• Relecture fine du contenu actuel de spring-boot.md nécessaire avant toute réécriture, pour ne rien perdre lors de l'extraction (391 lignes à trier entre "générique" et "propre à la v4").

Notes techniques

Hors périmètre de ce ticket mais lié : install-guidelines.js traite un fichier de version manquant comme un simple warning plutôt qu'une erreur bloquante (concatenateFiles, copyFile), et ne détecte pas non plus les doublons entre base et version. Un durcissement de ce comportement (fail-fast sur fichier absent, voire détection de sections dupliquées) mériterait un ticket dédié.