Support `vis[list[int]]` in `__getitem__` and `__setitem__`

[PythonFZ]

Summary

The ZnDraw client (vis) currently only accepts int | slice in __getitem__, __setitem__, and __delitem__. Users should be able to pass a list[int] for sparse index access, e.g.:

vis = ZnDraw(url="...")

# Read
frames = vis[[0, 5, 9]]          # → list[ase.Atoms]

# Write
vis[[0, 5, 9]] = [atoms1, atoms2, atoms3]

Current state

Layer	list[int] support
asebytes AsyncBlobIO	Read, set, update — all supported. Delete raises TypeError (by design: non-contiguous delete is ambiguous due to index shifting).
REST API (GET /v1/rooms/{room_id}/frames?indices=0,5,9)	Supported — indices query param already works.
ZnDraw.get(index, keys)	Supports int | list[int] | slice — already works.
ZnDraw.set_frames(index, value)	Supports int | list[int] | slice — already works.
ZnDraw.__getitem__	Only int | slice — missing list[int]
ZnDraw.__setitem__	Only int | slice — missing list[int]
ZnDraw.__delitem__	Only int | slice — cannot support list[int] (asebytes limitation by design)

Proposed changes

__getitem__

Add list[int] overload. Normalize negative indices, then call self.api.get_frames(indices=...) (already supported).

__setitem__

Add list[int] overload. Validate lengths match, then update each frame via self.api.update_frame() (same as current set_frames logic).

__delitem__

No change. Non-contiguous delete is not supported by asebytes and is ambiguous by nature (indices shift after each deletion). Users needing this can delete in reverse order manually.

Notes

• MutableSequence[ase.Atoms] does not require list[int] support, so this is a convenience extension.
• The get() and set_frames() methods already do this — the change is just adding the same support to the dunder methods.