docs: note pour mémoire sur le couplage au runtime async (pollster)

La lib n'a qu'un seul point de couplage au runtime (block_on dans app.rs) ; on ne crée volontairement
pas d'abstraction à ce stade. Consigné dans PLAN.md et ARCHI_APP.md : isoler derrière un module-pivot
unique si la lib acquiert d'autres appels async. Corrige aussi l'item check-list pollster devenu faux
dev-dependencies -> dependencies depuis la migration winit 0.30.

docs/tech/ARCHI_APP.md

@@ -72,6 +72,13 @@ pub trait AppHandler {
 - **`update()`** : appelé en premier. L'utilisateur peut modifier librement la scène (transformations, ajout/suppression d'entités). Ces modifications sont synchronisées vers le GPU via un **single buffer** Transform avant la passe de calcul.
 - **`render()`** : appelé après. Il ne sert qu'à injecter du rendu personnalisé (debug, HUD, etc.). La Scene reste immuable : aucune mutation d'état métier.
 
+> **Note pour mémoire (init GPU / runtime async)** : depuis la migration winit 0.30, l'init GPU
+> se fait dans le callback synchrone `resumed()`, donc via `pollster::block_on(Context::new(...))`
+> dans `app.rs`. C'est actuellement le **seul** point de couplage de la lib à un runtime async.
+> On ne crée volontairement pas d'abstraction tant qu'il n'y a qu'un appel ; si la lib acquiert
+> d'autres appels async, isoler le runtime derrière un module-pivot unique (`exec::block_on`),
+> seul fichier à modifier pour basculer vers tokio/futures-executor. Voir PLAN.md (note pour mémoire).
+
 ## 4. Workflow et Cycle de Vie
 
 ### A. Initialisation (Configuration)