one_viewr_flutter library

Client Flutter public d'Oneviewr CRM : identify (enregistrer un contact), track (événements), registerPushToken/unregisterPushToken (token push FCM/APNs).

Port direct de @oneviewr/js (neero-crm/sdk-js), avec les patrons d'architecture d'onex_client_plugin_flutter : façade statique unique (OneViewr), résolution d'environnement (OneViewrEnv/resolveApiBase), client REST séparé de l'état (OneViewrRestClient/ApiException), stockage local avec repli mémoire (KeyValueStore).

Surface publique normale : OneViewr — boot(), identify(), track(), registerPushToken(), unregisterPushToken(), checkInAppMessages(), ackInAppMessage(), setScreen(), answerInAppSurvey(), recordDeepLink(), deferredDeepLink(), resolveDeepLink(), reset(), plus IdentifyResult, OneViewrPlatform, PendingInAppMessage et DeepLink. Un intégrateur qui ne veut qu'identifier des contacts, envoyer des événements et afficher les messages in-app n'a besoin de rien d'autre.

Tout le reste est exporté en second rideau, pour l'hôte qui veut son propre stockage (KeyValueStore), sa propre source d'attribution d'installation (InstallAttribution, pour relayer un outil de mesure mobile), assembler son propre client REST, ou pour l'outillage/les tests — même philosophie que le fichier équivalent côté onex_client_plugin_flutter. showInAppMessage/InAppMessageWebView (src/ui/) en font partie : un hôte qui voudrait composer son propre écran autour du rendu WebView (plutôt que le Dialog/showModalBottomSheet posé par checkInAppMessages) peut les appeler directement.

Ce commentaire de bibliothèque ne fait qu'exporter (pas d'import), donc les symboles ci-dessus sont référencés en code inline (`), pas en liens dartdoc ([...]) — un lien exige que le symbole soit en réalité importé dans CE fichier, ce qu'un simple export ne fait pas.