feat: choose how frames are resized with interpolation

[alesanfra]

Description

• interpolation. read, read_batches, and FrameReader take interpolation: "nearest", "bilinear", "bicubic", "area", or "lanczos", each mapped to swscale's SWS_* flag. The default, None, stays bilinear on the CPU. An unknown name raises ValueError and lists the accepted ones.
• NVIDIA. NVIDIA's resizing method cannot be chosen, so naming an interpolation with device="cuda" turns off the resize of the *_cuvid decoders and lets the CPU resize the frames. With on_device=True it raises ValueError.
• SWS_FAST_BILINEAR is left out: on an Apple M2 it was no faster than bilinear at 960x540 or when enlarging, and it aliased heavily when shrinking.
• The API page, the new "Resizing" guide, the README, the landing page, and AGENTS.md describe the argument.
• Literal types. device and interpolation are typed as Literal, exported as iterframes.Device and iterframes.Interpolation and documented under Types in the API page. The extension still validates at runtime; tests check that the Literal types match the names it accepts.
• A separate commit updates uv.lock (dev and docs dependencies only: filelock, identify, markdown, nodeenv, platformdirs, pymdown-extensions, virtualenv).

The NVDEC tests were skipped locally, since the machine has no NVIDIA GPU, so the device="cuda" path is untested here.

Checklist

• cargo fmt and cargo clippy --all-targets -- -D warnings pass
• uv run --no-sync pre-commit run -a passes
• Tests added or updated, and uv run --no-sync pytest passes (103 passed, 3 skipped for NVDEC)
• Docs and CHANGELOG.md updated (the changelog is written by release-please); mkdocs build --strict passes

🤖 Generated with Claude Code