docs: document jsonStringify for writing and clarify the .0 integer convention

ccip-api-ref/docs-cli/guides/reading-json-output.mdx

@@ -41,6 +41,21 @@ parsed.request.lane.sourceChainSelector
 If you're not importing the SDK, [`lossless-json`](https://www.npmjs.com/package/lossless-json)
 solves the same problem.
 
+To write data back out, use `jsonStringify` from the same package. Plain `JSON.stringify` throws
+on the `bigint` values `jsonParse` returns:
+
+```typescript
+import { jsonParse, jsonStringify } from '@chainlink/ccip-sdk'
+
+const parsed = jsonParse<ShowOutput>(stdout)
+
+JSON.stringify(parsed) // TypeError: Do not know how to serialize a BigInt
+jsonStringify(parsed) // works, full precision preserved
+```
+
+Use the two together, or neither. Fields read this way are `bigint`, so compare them against a
+`bigint` literal (`11n`), not a `number` literal (`11`).
+
 ## jq
 
 jq 1.7 and later keep large integers as literal text through passthrough and field selection. Any

ccip-api-ref/docs-sdk/guides/json-integer-precision.mdx

@@ -61,6 +61,12 @@ jsonParse<{ amount: bigint; note: string }>(encoded)
 `.0` suffix by `jsonStringify`, e.g. `2.0`), so `{"a":1,"b":2.0}` round-trips as `{ a: 1n, b: 2 }`,
 not `{ a: 1n, b: 2n }`.
 
+The `.0` suffix is a convention, not a requirement. `2.0` and `2` are the same JSON number. The
+suffix only marks a value as safely castable to a `number`, opting out of the `bigint` default.
+Every numeric input in the SDK's public interfaces accepts `number` or `bigint`, so a value from a
+source that doesn't carry the convention (Python, Go, and Postgres all emit `2`) still comes back
+as a `bigint` and still works.
+
 ## Other consumers
 
 - Python: `json.loads` parses JSON integers as arbitrary-precision `int` natively. No special