fix: coerce money fields to integers before API calls

[wzul]

Summary

CHIP Collect requires money fields (price, discount, total_price_override, capture/refund amounts, totals and overrides) as integers in minor units (sen).

Apps computing sen via floating point (e.g. 0.29 * 100 → 28.999999999999996) were sending fractional JSON numbers, and the API rejects them with:

400 Bad Request
{"purchase":{"products":[{"price":{"message":"A valid integer is required.","code":"invalid"}}]}}

Verified live against the test-mode API:

• 108 / 108.0 / "108.00" → 201 OK
• 28.999999999999996 (float noise) → 400 (exactly the merchant-reported error)

This is not a magnitude rule — it is binary-float rounding noise occurring for arbitrary values (any ringgit × 100 whose result is not exactly representable).

Failure modes closed by this PR

SDK version	Before	After
v1.x-style model path (all 1.x, and v2 model path)	fractional float sent verbatim → 400	coerced to nearest integer (within 1e-9) → 201
v2 PurchaseBuilder	int $price weak-mode coercion silently truncated sen (28.999… → 28, wrong amount)	rounds within epsilon; genuine fraction (108.5) explodes loudly instead of charging the wrong price

Changes

• Chip\Support\Money::coerce() — shared helper: numeric within 1e-9 of an integer → that integer (covers float noise, int-valued floats, numeric strings like "108.00"); genuine fractional sen → Chip\Exception\InvalidMoneyValueException; null passes through.
• Product — coerce price/discount/total_price_override in fromArray() and at jsonSerialize() time (public properties mean v1-style direct assignment still reaches the API clean).
• PurchaseDetails — coerce total/debt/subtotal_override/total_tax_override/total_discount_override/total_override in both directions.
• PurchaseBuilder — money params widened to int|float|string, coerced explicitly (no more silent weak-mode truncation).
• PurchasesResource::capture()/refund() — amount widened + coerced.
• InvalidMoneyValueException extends ChipApiException so existing catch blocks keep working.
• Removed pr-summary.yml + scripts/generate_pr_summary.py — the Ollama endpoint now returns 410 Gone and the workflow was overwriting PR bodies with its error output (it corrupted this very PR's description on first push).

Test Plan

• composer test — 110 tests, 352 assertions OK (15 new in tests/MoneyCoercionTest.php: float noise, numeric strings, genuine fractions, NaN, serialization + builder paths)
• composer phpstan — level 8, no errors (conditional return type on Money::coerce)
• composer cs-check — clean
• Live E2E vs test-mode API: previously-failing manual model path now returns 201, fraction 108.5 rejected with precise message naming the field