feat(technique) : module Technique + taxonomie categories prestataires

Cree le nouveau module Technique (pole distinct du Commercial) prerequis du
M3 repertoire prestataires :
- TechniqueModule (ID=technique, REQUIRED=false) + 5 permissions RBAC
  technique.providers.* (view / manage / accounting.view / accounting.manage
  / archive), declarees pour app:sync-permissions.
- Activation dans config/modules.php + layer front frontend/modules/technique/.
- Seed taxonomie : nouveau CategoryType PRESTATAIRE + 3 categories
  (Maintenance industrielle, Nettoyage, Transport) via migration idempotente
  (ON CONFLICT / NOT EXISTS, jonction M2M category_category_type) ET fixtures
  CategoryType/Category (survivent au purger db-reset).
- Tests : structure du module (5 permissions figees) + filtre
  GET /api/categories?typeCode=PRESTATAIRE.

Inclut la spec back/front M3 et le RETEX M1.

src/Module/Technique/TechniqueModule.php

@@ -0,0 +1,58 @@
+<?php
+
+declare(strict_types=1);
+
+namespace App\Module\Technique;
+
+/**
+ * Module Technique (M3) — pole distinct du Commercial qui porte le repertoire
+ * prestataires (entites Provider* livrees par les tickets suivants du M3).
+ *
+ * Decision Matthieu (11/06/2026) : le repertoire prestataires vit dans un
+ * module a part entiere « Technique » (et non sous Commercial), conformement au
+ * docx source. Ce module est activable/desactivable comme les autres
+ * (cf. config/modules.php), non requis au boot.
+ *
+ * Au ticket 1.1, le module ne porte encore aucune entite : il declare seulement
+ * son identite et son jeu de permissions (cf. spec-back M3 § 2.1 + § 5.1). Le
+ * cablage de la section sidebar « Technique » et l'attribution des permissions
+ * aux roles interviennent avec l'ecran prestataires (tickets ulterieurs).
+ */
+final class TechniqueModule
+{
+    public const string ID     = 'technique';
+    public const string LABEL  = 'Technique';
+    public const bool REQUIRED = false;
+
+    /**
+     * Liste declarative des permissions RBAC exposees par le module Technique.
+     *
+     * Consommee par la commande `app:sync-permissions` (SyncPermissionsCommand)
+     * qui se charge d'upserter ces entrees dans la table `permission`, de
+     * reactiver les codes precedemment marques orphelins et de marquer comme
+     * orphelins ceux qui ont disparu du code source.
+     *
+     * La cle `module` est auto-injectee par le sync command a partir de
+     * `self::ID`, il est donc inutile de la repeter dans chaque entree.
+     *
+     * Convention de nommage des codes : `module.resource[.sub].action` en
+     * snake_case, le prefixe module devant correspondre exactement a
+     * `self::ID` (verifie par la commande de synchronisation).
+     *
+     * Granularite alignee sur Commercial (les prestataires sont le jumeau des
+     * fournisseurs) : view + manage, plus deux permissions dediees a l'onglet
+     * Comptabilite et une a l'archivage (cf. spec-back M3 § 2.9 + § 5.1).
+     *
+     * @return array<int, array{code: string, label: string}>
+     */
+    public static function permissions(): array
+    {
+        return [
+            ['code' => 'technique.providers.view', 'label' => 'Voir les prestataires'],
+            ['code' => 'technique.providers.manage', 'label' => 'Créer / modifier les prestataires (hors onglet Comptabilité)'],
+            ['code' => 'technique.providers.accounting.view', 'label' => 'Voir l\'onglet Comptabilité d\'un prestataire'],
+            ['code' => 'technique.providers.accounting.manage', 'label' => 'Modifier l\'onglet Comptabilité d\'un prestataire'],
+            ['code' => 'technique.providers.archive', 'label' => 'Archiver / restaurer un prestataire'],
+        ];
+    }
+}