[niemyjski]

Stacked on #587. Custom list sizing was building an immutable index and then copying it into a dictionary for each write. Update the required private dictionary directly, and preserve cheap unchanged updates. The shared expiration test now avoids its narrow scheduling window, with fake-time coverage for small/large and scoped lists.

Validation at 988ab9ff: Release build, formatting, and 2,479 tests passed / 22 existing skips. Final combined core: 2,517 passed / 22 skips; Redis cache/lock validation: 778 passed / 18 skips, including the revised expiration test in all four provider fixtures. Push CI and PR CI passed.

Still held for performance review: compatible custom sizing with cloning disabled remains 3.28× main's time / about 300× allocation at 10,000 items. This reduces overhead but does not eliminate the cost of preserving concrete-dictionary callbacks. The read-only option remains explicit.

Verification and implementation details

Base: #587 at f891a9b0808cdea5585ce393b78be1827b78c6ed. Head: 988ab9fff045af312715da76d69ccc24228b42e3.

The custom-calculator path skips indexing and updates one private dictionary copy. Rejected replacements retain the previous value, expiration and tracked size. Unchanged list additions reuse values and reapply the list expiration without rerunning the calculator. Existing comparer and cloning rules remain. No public API or option-default change.

Regression-first evidence: the allocation budget failed before the change; a separate unchanged-update regression caught unnecessary copying in the initial optimization and was corrected before publication. Coverage includes both cloning modes. An injected 200 ms pause reproduced the original shared expiration-test failure in all seven core fixtures. The revised shared test uses a permanent surviving item and verifies whole-key expiry on a fresh list. Twelve fake-time cases cover overlapping finite expirations on small/large and scoped lists. Redis's existing return-count and permanent-key TTL semantics are preserved.

Final measurements: BenchmarkDotNet 0.15.8, .NET 10.0.14 arm64, Apple M4 Max, one launch, three warmups, seven measured iterations. Each operation adds then removes one item after warmup; a fixed clock prevents background expiry. Main be10785c, previous #587 and this candidate were loaded in separate assembly contexts with SHA-256 verification and identical bound-delegate calls. Twenty-four measured cases cover 1,000/10,000 items, cloning on/off, and compatible/read-only sizing. These measurements do not establish cold-write or contention costs.

Items, cloning off	Main	Before	Candidate	Candidate read-only
1,000	3.857 µs / 2.38 KiB	10.240 µs / 85.53 KiB	9.177 µs / 80.32 KiB	1.094 µs / 7.70 KiB
10,000	33.390 µs / 2.38 KiB	130.500 µs / 735.27 KiB	109.351 µs / 713.39 KiB	2.762 µs / 24.38 KiB

The candidate is about 16% faster than the previous stack for 10,000-item compatible sizing, with about 3% less allocation. Cloning-on compatible sizing is faster than main and uses about half its allocation in these integer-list cases. Read-only sizing avoids the full dictionary copy but still allocates immutable update structures. The guide now states the remaining linear allocation cost and scopes its DateTime.Kind note accurately.

Redis 8.10.3 ran against an isolated combined candidate including #586, using source references and explicit registration of the shared contracts. The 30 lock cases and 12 added direct/scoped cache cases remain an isolated validation overlay; durable provider registration work is separate. Existing six Hybrid concurrency and three FastCloner core skips are retained. The final combined source-provider build passed with two existing ASPIRE010 warnings after an isolated RabbitMQ MessagePack 2.5.303 pin; unmodified RabbitMQ main still fails NU1902. Fresh binary API checks passed. The core AppHost dependency correction is extracted separately in #599. No workflow changes, merge, or manual release.