Historique des rechargements wallet

# Instructions — Historique des rechargements wallet

## ⚠️ Format de date : ISO 8601 + timezone recommandé

La documentation MCP indique que YYYY-MM-DD seul n'est pas accepté et qu'il faut un datetime complet.
Le schéma d'entrée impose le format `date-time` et le serveur valide les formats : `from="2026-06-01"` est refusé à la validation.

**Malgré ce comportement tolérant, toujours utiliser ISO 8601 complet avec timezone :**
```
from: "2026-06-01T00:00:00.000Z"
to:   "2026-06-30T23:59:59.999Z"
```

Raison : la coercion de YYYY-MM-DD vers midnight peut produire des résultats inattendus selon la timezone du serveur. L'utilisation de `T00:00:00.000Z` (UTC) est non ambiguë.

## ⚠️ Pas pour la réconciliation bancaire exacte

`createdAt` est la **date de comptabilisation du prestataire bancaire** (la date de valeur sur les comptes GBP).
Les filtres `from`/`to` ne filtrent pas de façon fiable sur `createdAt` : sur les wallets `sfs` hors GBP ils portent sur la date de création de l'enregistrement, sur les wallets GBP c'est le prestataire bancaire qui décide, et sur les anciens wallets (`bankName: other`) les rechargements par carte et SEPA ignorent `from`/`to`.
→ Élargir `from`/`to` de quelques jours, puis appliquer la coupure soi-même sur `createdAt`.
→ Pour la réconciliation exacte, vérifier contre le relevé bancaire.

## ⚠️ Cache 24h (86400 secondes)

Le cache s'applique par requête identique (mêmes `page`, `pageSize`, `cursor`, `from`, `to`) : un rechargement reçu après un premier appel identique peut ne pas apparaître avant 24h.
→ Pour le solde courant, utiliser `get_wallet_summary` — il est servi depuis un cache court, donc récent mais pas temps réel.

## Étape 1 — Appel avec période et paramètres recommandés

```json
{
  "companyId": "...",
  "from": "YYYY-MM-DDT00:00:00.000Z",
  "to": "YYYY-MM-DDT23:59:59.999Z",
  "pageSize": 100
}
```

## Étape 2 — Interpréter les champs

Pour chaque load :
- `amount` : `{ amount, currency, precision }` → montant = `amount / 10^precision` EUR
- `type` : `"wireTransfer"` (seul type observé sur ce compte)
- `bankName` : `sfs` | `adyen` | `other`
  - `sfs` = Spendesk Financial Services (compte principal)
  - `adyen` = Adyen (comptes de certaines filiales)
  - `other` = tout autre prestataire bancaire (anciens wallets ; les rechargements par carte et SEPA y ignorent `from`/`to`)
- `createdAt` : date de comptabilisation du prestataire bancaire (la date de valeur sur les comptes GBP) — ce n'est pas la date de création de l'enregistrement dans Spendesk

## Étape 3 — Pagination

Vérifier `meta.pagination.hasNextPage` — si `true`, paginer avec `page=2, 3, ...` et les mêmes filtres.

**Wallets GBP** (`bankName: sfs` avec montants en GBP) : `page` est ignoré. Quand il reste des rechargements, la réponse contient `meta.pagination.cursor` : le repasser dans `cursor` avec les mêmes `from` et `to`, jusqu'à ce que `hasNextPage` soit `false`. `fetchAll` suit le curseur tout seul et ne se combine pas avec `cursor` ; s'il est tronqué, il renvoie `meta.pagination.resumeCursor` à la place de `resumePage`.

## Exemple live (données réelles, juin 2026)

16 loads en juin 2026, dont :
- 2026-06-23 : 500 000,00 EUR (virement sfs)
- 2026-06-10 : 600 000,00 EUR (virement sfs)
- Totalité du mois : ~1 105 721 EUR (incluant deux grands chargements tests)

## Exemple de prompt

- "Montre les rechargements wallet du mois dernier" → from/to = mois dernier + ISO 8601
- "Combien avons-nous chargé le wallet en 2026 ?" → from=2026-01-01T00:00:00.000Z, to=aujourd'hui + pagination
- "Quel est le solde actuel du wallet ?" → utiliser `get_wallet_summary`, pas `get_wallet_loads`