avm2: Treat hasnext2/nextname/nextvalue index as u32

[SuchAFuriousDeath]

Description

Fixes #11181.

The hasnext2, nextname, and nextvalue opcodes coerced their enumeration cookie to i32 and treated negative values as end-of-iteration. ArrayStorage::Sparse::get_next_enumerant returns key + 1 as the cookie, so
as soon as the enumeration reached a sparse index >= 2^31, the cookie wrapped to a negative i32 and iteration terminated. Callers ended up with null in the middle of the enumerated sequence and every key past that
point was lost.

Boxhead the Nightmare (issue #11181) writes a SharedObject whose objects field is a sparse Array keyed by 32-bit hashTag values. Restoring that save into Ruffle dropped every key >= 2^31; FDataFields/set objects()
then walked the array and hit TypeError #1009 accessing field: hashTag, aborting boot.

This restores the pre-e7ee3d3e1 (#18958) u32 semantics, which match avmplus. op_has_next is left as-is — the legacy hasnext opcode is not covered by the new test and modern ASC only emits hasnext2. Someone can flip
it in a follow-up.

Checklist

• I, a human, have self-reviewed this PR and fully understand the changes within.
• I have made or updated tests where possible.
• All of my commits are properly scoped, compile successfully, and pass all tests.
• This PR does not make sense to split up into smaller PRs.
• An LLM was involved in the authoring of this code.

[kjarosh]

LGTM, but would be nice if @Lord-McSweeney or @adrian17 took a look as well

[Lord-McSweeney]

From its source, avmplus always coerces the index passed to nextname, nextvalue, and hasnext(2) to an int. Is there some evidence suggesting otherwise?

[kjarosh]

Does the test fail without changes from this PR?

[SuchAFuriousDeath]

Does the test fail without changes from this PR?

Yes

[SuchAFuriousDeath]

From its source, avmplus always coerces the index passed to nextname, nextvalue, and hasnext(2) to an int. Is there some evidence suggesting otherwise?

The game not working as well as the test.

[kjarosh]

As mentioned on Discord,

ArrayStorage::Sparse::get_next_enumerant returns key + 1 as the cookie

This is the root cause, not the fact that we stop iteration for negative int values. Sadly, those indices are untested in ruffle that's why the tests pass here.