```
ListIterator claimed random_access_iterator_tag, but operator* returns a
proxy, which C++17 forbids for forward-or-better iterators. Sets
iterator_concept = random_access_iterator_tag (the C++20 point that does
allow proxies); iterator_category stays explicit input_iterator_tag rather
than synthesized, since GCC 11 synthesizes something legacy std::reverse/
std::sort can't dispatch on. Fixed the 8 call sites that called those
directly on List<T> iterators (shape_analysis.cpp, register_ops_utils.{h,cpp},
register_prim_ops.cpp) to use std::ranges::sort/reverse instead.

<=> is hand-written, not defaulted: libc++'s __wrap_iter has no <=> of its
own, so a defaulted <=> is implicitly deleted on macOS, failing every
iterator concept. Derived from < instead.

Const-qualifies the proxy's assignment operators for indirectly_writable,
and adds iter_move/iter_swap so move-based algorithms steal the underlying
IValue instead of copying - e.g. freeze_module.cpp's overrideGradient loop
(extract -> overrideGradient by value -> set) is now copy-free per element.

Second commit: List::emplace forwarded args straight into
std::vector<IValue>::emplace, so they picked whichever IValue overload they
named instead of T's - List<double>().emplace(pos, 1) stored an Int, not a
Double. Construct T first, matching push_back.

Test Plan:

static_assert checking the iterator concepts hold for four element types,
plus regression tests for use_count and emplace. Compiled against GCC 16
and real libc++ since this machine's torch build is stale; the GCC 11 and
macOS CI failures from earlier pushes surfaced the two fixes above.
```

Drafted with AI assistance (Claude Code).
Pull Request resolved: https://github.com/pytorch/pytorch/pull/196002
Approved by: https://github.com/Skylion007