docs: add decimal footgun section to use-arc skill

[erhnysr]

Summary

Small, focused addition to the existing use-arc skill: a new Common Pitfalls → The Decimal Footgun section that reinforces the existing decimal guidance with a concrete, real-world example.

Motivation

Arc uses USDC as its native gas token, which makes it easy to assume every amount uses 18 decimals like a typical EVM chain — when in fact ERC-20 USDC uses 6 decimals and only native gas (msg.value) uses 18. This is a real trap: we hit exactly this decimal mismatch in one of our own projects (a USDC payment flow), where parseEther was used instead of parseUnits(amount, 6), producing an amount 10^12 times too large. We wrote it up in a Paragraph article (https://paragraph.com/@coliseum/the-18-vs-6-decimal-footgun-on-arc-what-nearly-killed-coliseum) as a lesson learned, and this PR distills that experience into the skill so other builders (and agents) avoid the same mistake.

What's added

• A concrete failure scenario with real numbers (parseEther('10') → 10^18 vs parseUnits('10', 6) → 10^6, a 1,000,000,000,000x error)
• A ❌ WRONG / ✅ CORRECT TypeScript/viem code comparison
• A one-line rule to remember
• A note on why it's dangerous: can revert on insufficient balance, or worse, silently succeed with a wildly wrong amount

Consistency

This complements — and does not duplicate — the existing "Dual decimals" Core Concept and the Best Practices decimal rule. It follows the same markdown style, code-block conventions, and tone as the rest of the file.

[mistycornish11-stack]

attachments/assets/3c3f4eb7-e902-4a30-af44-469cf72fd4d9)
attachments/assets/8d32f70f-5cc4-48aa-be17-d6021ed8d009)
attachments/assets/179b8a29-7230-4e22-8b49-25b80729ed6e)

[mistycornish11-stack]

I have more than one asset
USDC, XRPL & XLM
MistyCornish11@gmail.com
409)372-8223
I’m 52 F and I live in Texas City, 77590

[erhnysr]

@bryan-anthropic heads up — the two comments above from mistycornish11-stack are off-topic spam containing personal info (email, phone, location) unrelated to this PR. I already reported them via GitHub's content report, but they're still visible. Could you hide/minimize them when you get a chance?