doc: split Architecture.md into per-topic pages

doc/Architecture.md was 436 lines and growing; this commit
extracts each non-trivial subject into its own page under
doc/architecture/ and reduces the root document to a table of
contents + transversal sections (vision, stack, admin rights).

New pages (under doc/architecture/):

- workflow-multi-parties.md : client / fournisseur /
  coordinateur roles, sous-traitance, project states, B2B/B2C,
  domaine musical production flow.
- domaine-musical.md : titres collaboratifs (formats, flux de
  production, contraintes de licence).
- licences.md : LicenceModele, CC/ODbL seed, badge projet,
  cycle de vie.
- domaines-activite.md : arbre des activites, Droit a la
  racine, DomaineActivite model.
- dictionnaires-metier.md : regle d'heritage, DictionnaireMetier
  + TermeMetier, cycle de vie d'un terme. Absorbs the previous
  doc/Dictionnaire.md draft.
- offres-frontmatter.md : ClasseFormulaire / ClasseDevis,
  OffreFournisseur, Demande, parsing YamlDotNet (introduit dans
  4034c399 Front matters). Absorbs the previous
  doc/Formulaires-devis.md and doc/Demande.md fragments.
- postit-oidc.md : documentation du client desktop PostIt,
  custom URI scheme (RFC 8252 §7.1), composants partages,
  plateformes, UX observable, persistance et reprise au boot,
  garanties testees.

Architecture.md (436 -> 66 lines) keeps the vision, the stack
overview, the admin rights section, and a TOC table pointing at
each detail page. The "A documenter ensuite" backlog is kept
at the end.

Cross-links are relative: from Architecture.md the links go
architecture/<page>.md; from inside doc/architecture/ they go
../Architecture.md or <sibling>.md.

doc/architecture/offres-frontmatter.md

@@ -0,0 +1,106 @@
+# Offre fournisseur, formulaire, devis
+
+> **Récapitulatif** : Le fournisseur rédige son offre en Markdown
+> avec un en-tête frontmatter YAML qui pointe vers un
+> `ClasseFormulaire` et un `ClasseDevis` définis par les
+> modérateurs. La demande du client instancie les champs du
+> formulaire. L'héritage suit l'arbre des activités. Détail dans
+> cette page, racine de l'architecture : [Architecture.md](../Architecture.md).
+
+> Note historique : des fragments existaient à `doc/Formulaires-devis.md`
+> et `doc/Demande.md`. Ils sont absorbés ici.
+
+## Principe
+
+Un fournisseur décrit son offre en **Markdown**, avec un en-tête
+structuré délimité par `---` (frontmatter YAML standard) qui porte
+les métadonnées de formulaire et de devis. Le corps est libre.
+
+```markdown
+---
+formulaire: Prestation Musicale
+devis: Arrangement Orchestral
+---
+
+Je propose des arrangements pour orchestre de chambre,
+livraison sous 3 semaines, formats MusicXML et PDF...
+```
+
+## `ClasseFormulaire` et `ClasseDevis`
+
+Ces deux référentiels sont **définis côté serveur par les
+modérateurs**, pour servir de modèles de formulaires et de devis.
+Les fournisseurs s'y conforment — ils ne peuvent pas en créer
+de nouveaux.
+
+## Modèle canonique nom/valeur
+
+```
+ClasseFormulaire
+  - Id, Nom
+  - DomaineActiviteId (FK)
+  └── ChampDemande
+        - Nom          (ex : "tempo", "tonalité", "durée")
+        - TypeValeur   (texte | entier | décimal | booléen | enum)
+        - Obligatoire  (bool)
+        - ValeurDefaut
+
+ClasseDevis
+  - Id, Nom
+  - DomaineActiviteId (FK)
+
+OffreFournisseur
+  - Id
+  - FournisseurId     (FK → ApplicationUser)
+  - DomaineActiviteId (FK)
+  - ContenuMarkdown          ← corps libre de l'offre
+  - ClasseFormulaireId (FK)  ← extrait du frontmatter à la sauvegarde
+  - ClasseDevisId      (FK)  ← extrait du frontmatter à la sauvegarde
+```
+
+## Demande client
+
+À partir de l'offre, la demande instancie les champs du formulaire :
+
+```
+Demande
+  - Id
+  - OffreFournisseurId (FK)
+  - ClientId (FK → ApplicationUser)
+  └── ValeurChampDemande
+        - ChampDemandeId (FK)
+        - Valeur (string — sérialisé selon TypeValeur)
+```
+
+## Règle d'héritage
+
+Les `ClasseFormulaire` et `ClasseDevis` disponibles pour une
+activité incluent ceux de ses **ancêtres** dans l'arbre —
+cohérent avec la règle de résolution des dictionnaires
+([dictionnaires-metier.md](dictionnaires-metier.md)).
+
+## Parsing du frontmatter avec YamlDotNet
+
+Le parsing du frontmatter vit dans
+`src/Yavsc.Server/Services/FrontmatterParser.cs` (introduit dans
+le commit `4034c399 Front matters`). Squelette :
+
+```csharp
+var parts = markdown.TrimStart()
+                    .Substring(3)
+                    .Split(new[] { "\n---" }, 2,
+                           StringSplitOptions.None);
+var yamlBlock = parts[0].Trim();
+var corps     = parts[1].Trim();
+var meta = deserializer.Deserialize<FrontmatterOffreResult>(yamlBlock);
+```
+
+Le résultat `FrontmatterOffreResult` est sérialisé en JSON pour
+alimenter `OffreFournisseur.ClasseFormulaireId` /
+`ClasseDevisId` à la sauvegarde.
+
+## Voir aussi
+
+- [Architecture.md](../Architecture.md) — racine.
+- [domaines-activite.md](domaines-activite.md) — arbre des
+  activités et héritage.