Keep number expectations within binary64

An exact decimal identifier needs an agreed representation, not hope about a receiver’s number type.

• IEEE754 binary64, often called double precision, is widely available. I-JSON senders cannot assume a receiver supports greater magnitude or precision. Messages SHOULD NOT include numbers expressing more than binary64 provides, such as 1E400 or the RFC’s long decimal π example (§2.2). This is SHOULD NOT, not a universal grammar ban or MUST reject.
• The published interoperability statement uses the consecutive-integer interval −9007199254740991 through9007199254740991, or ±(2^53−1). A sender cannot expect integers outside it to arrive as exact values. Some individual integers outside it are representable; the interval is not the entire range of finite binary64 numbers (§2.2).
• The illustrative decimal integers9007199254740992 and9007199254740993 both become9007199254740992 in JavaScript Number. That demonstrates a collision, not a claim that every out-of-range integer rounds or is invalid JSON. Reported technical erratum5354 proposes changing the printed bound to±2^53; it is unverified and is not adopted here.
• For applications requiring exact exchange of larger or higher-precision numbers, JSON strings are RECOMMENDED. The example {"id":"9007199254740993"} preserves its digits, but the receiving program must know this string is an identifier or exact number. A string alone supplies no arithmetic semantics (§2.2).
• The bounded helper retains raw numeric tokens and shows their JavaScript interpretation; it reports selected binary64 magnitude/safe-integer advice separately from profile MUST violations. A chosen exact-ID consumer can stop a numeric value that cannot satisfy its contract. That local decision is not a universal I-JSON error response.