Gleam integration tests with large API IDs: gleeunit suite behaves differently across Erlang and JavaScript targets

I'm designing an integration test suite for a Gleam service that talks to an external API. Following the documented gleam test workflow with gleeunit, the plan is to inject configuration (base URL, token) via environment variables and pass a fake HTTP client into the application code so tests return canned gleam/http responses instead of hitting production. No real credentials would ever be needed in CI.

The unresolved concern is test fidelity across compilation targets. The same suite is intended to run on both the Erlang target and the JavaScript target, and the upstream API returns very large integer identifiers. My understanding is that Gleam's Int is arbitrary precision on Erlang but constrained by JavaScript's safe-integer range, which suggests decoding or comparing those IDs could behave differently per target even though the test code is identical.

Assume a recent Gleam toolchain with current gleeunit; exact versions to be confirmed before implementation.

Is target-dependent integer representation the right explanation for potential cross-target divergence in such a suite, and how do teams normally structure ID handling so one test codebase stays valid on both targets? Is there a documented convention for gating or marking target-specific tests in gleeunit, given it has no built-in tagging mechanism?