Interop: an index outside a wrapped collection is refused, not handed to the collection

[lahma]

Fixes #3422.

A plain ObjectWrapper over a bounded CLR collection hands an out-of-range index straight to the host. The
target is an ordinary embedder shape — a window with a Count and an int this[int], exposed under its own
type — and nothing about it is exotic or AOT-only:

sealed class Window : IReadOnlyCollection<int>
{
    public int this[int index] { get => _items[index]; set => _items[index] = value; }
    public int Count => _items.Count;
    // ...
}

// main, three elements, options.Interop.AllowWrite = true
x[3]                    // ArgumentOutOfRangeException out of Evaluate — a read
x["3"]                  // ArgumentOutOfRangeException
x[3] = 9                // ArgumentOutOfRangeException
x["3"] = 9              // ArgumentOutOfRangeException
x[-1] = 9               // ArgumentOutOfRangeException
x["08"] = 9             // ArgumentOutOfRangeException
Reflect.set(x, 3, 9)    // ArgumentOutOfRangeException
3 in x                  // true — for a position that cannot even be read

None of those is a JavaScriptException, so neither a script try/catch nor a host
catch (JavaScriptException) sees them. #3384 gave an ArrayLikeWrapper ownership of every index-shaped key,
but the refusal lives in the array-like view and this shape does not get one: the target is not an
IList<T>, not an IReadOnlyList<T> and not a non-generic IList, so it is wrapped plainly and every
index-shaped key resolves the reflected indexer, which takes whatever index it parsed out of the key to the
collection.

The guard cannot go where #3384 put its, because a plain wrapper's indexer lane also serves
Dictionary<int, string>, where d[99] = "x" is a legitimate add. So it is conditioned on two facts at
once: the type descriptor reports array-like (a Count, and not a dictionary), and the member the wrapper
is about to resolve is an integer-keyed indexer. A key that is index-shaped and outside [0, Count) — or
index-shaped and never addressable at all, -1, "08", "+3" — is then answered by the wrapper:

// this PR
x[3]                    // undefined
x["3"]                  // undefined
x[3] = 9                // sloppy: silently ignored;  strict: TypeError
3 in x                  // false
x.hasOwnProperty(3)     // false
delete x[3]             // true — there was nothing to delete

x[99] = 'a' on a Dictionary<int, string> still adds, and a string-keyed indexer on an array-like target —
a NameValueCollection asked for x["3"] — still answers for its own key, because the check reads the
resolved accessor's index parameter rather than guessing from the key. Positions the collection does have,
and every named CLR member, are untouched.

ElementKey / ClassifyElementKey move from ArrayLikeWrapper up to ObjectWrapper, unchanged. One
definition of "index-shaped key" is the point of #3384; a second copy here is the thing that would drift.

Proof

Jint.Tests.PublicInterface/HostCollectionIndexBoundsTests.cs is new. Against unmodified main, 28 of its
35 cases fail — seven keys (3, "3", 10, -1, "-1", "08", "+3") across four questions:

Failed ReadingAnIndexTheCollectionCannotAddressAnswersUndefined(x7)
    System.ArgumentOutOfRangeException : Index was out of range. Must be non-negative and
    less than the size of the collection. (Parameter 'index')

Failed WritingAnIndexTheCollectionCannotAddressIsTheOrdinarySetRefusal(x7)
    same exception, out of engine.Execute("x[3] = 9")

Failed EveryExistenceLaneAgreesThatSuchAnIndexIsAbsent(x7)
    Expected ... to be the same string because 3 is not a position of the collection,
    so no lane may report it as one, but they differ at index 0

Failed DeletingSuchAnIndexSucceedsWithoutTouchingTheCollection(x7)
    Expected boolean to be True because OrdinaryDelete returns true for a property that
    is not there, but found False

Failed!  - Failed: 28, Passed: 7, Skipped: 0, Total: 35

The seven that pass on main are the contrast cases and still pass: the four in-range positions, the named
CLR members, the integer-keyed Dictionary that must keep adding, and the string-keyed indexer that must keep
answering for its own key.

docs/v5-migration.md §4.56 carries the embedder-facing form, and Jint/Runtime/Interop/AGENTS.md gains the
rule that #3384, #3423 and this one share.

Merge after #3464 (the ArrayLikeWrapper half of the same invariant): the two touch neighbouring code in
the same two files, and this one needs a rebase once that lands.