Respect custom strides in scalar compound assignment

[CAOShurong]

Checklist

• The title and commit message(s) are descriptive.
• Small commits made to fix your PR have been squashed to avoid history pollution.
• Tests have been added for new features or bug fixes.
• API of new functions and classes are documented (no public API changes).

Description

Fixes #2773.

Scalar compound assignment currently writes the storage prefix even when an adaptor has padded strides. Use logical iteration for non-dense strides, while preserving physical iteration for dense layouts, including custom axis permutations. Dense-layout traversal preserves the behavior of aliased scalars and stateful, noncopyable functors.

Tests cover padded rows and columns, empty adaptors, scalar aliasing and functor state for both dynamic- and fixed-rank adaptors.

Validation: 26 adaptor cases (114 assertions), installed CMake consumers, and 224 owned-buffer checks under AddressSanitizer passed. A partial broader run passed 1,219 cases from the 77 test modules that compile on MSVC 19.42; the full build encounters the same baseline errors in test_xfunction and test_xvectorize.

Local microbenchmarks found up to ~1.7 ns overhead for 16-element arrays; large-array candidate/baseline ratios reached 1.13x. Linux and macOS validation remains to CI.

[codspeed]

Merging this PR will degrade performance by 18.92%

⚠️ 1 benchmark measured no execution time

Nothing ran under measurement, usually because the compiler removed the code under test. This result is not comparable, so it counts as unchanged.

Preventing compiler optimizations

• create_xview

❌ 1 regressed benchmark
✅ 254 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	xshape_access[xt\:\:svector<std\:\:size_t, 4>]	125 ns	154.2 ns	-18.92%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing CAOShurong:codex/fix-strided-scalar-assignment (821ea73) with master (8e14e7b)}

[CAOShurong]

I investigated the shape benchmark using the reported base 8e14e7b and head 821ea73, GCC 13.3, and CodSpeed runner 4.19.1. Reproducer and raw profiles.

The shape translation unit has identical dependencies and disassembly, and does not include the changed xassign.hpp. Both builds execute 21 instructions, 6 reads and 3 writes for svector; the head has one additional simulated instruction-cache miss (3 vs 2).

Relinking the same objects with the shape object first gives it the same address in both binaries, and all four shape benchmarks then have identical counters. This points to code-placement sensitivity in the simulation. The PR code is unchanged. Could you assess whether this CodSpeed result can be acknowledged?