Add a batch read/write API to LocalDictionary

[imranakram]

What

Every indexer, ContainsKey and TryGetValue call is its own SQL round trip, so a caller
looping over keys pays a round trip per key. At 100 000 keys that is ~92 s of reads and ~78 s
of writes against a warm database — the profile the MMS-8327 fee run was stuck in.

PersistentBlobCache already had the batch primitives, Get(IEnumerable<string>) and
Insert(IDictionary<string, byte[]>), chunking at 950 keys per statement. LocalDictionary
just exposed no way to reach them.

How

IBulkDictionary<T>	GetRange(keys) / SetRange(items). A separate interface from IDictionary, so a consumer holding only the interface can test for it and fall back.
LocalDictionary<T>	implements it, routing both members to the batch primitives
DictionaryExtensions	the same two methods as extensions on IDictionary<string, T> — batch path when the target supports it, per-key loop when it does not

The extension pair is what lets a caller that holds an IDictionary<string, T>, not knowing
whether it is in memory or persistent, get the batch behaviour without a type check.

Numbers

100 000 keys holding IList<Entity> of five attributes each, .NET Framework 4.8 x64, warm
database:

	Per-key loop	GetRange / SetRange, blocks of 1 000
Reads	~92 s	1.27 s
Writes	~78 s	75.94 s -> ~3 s with Xrm.Json.Serialization 1.2026.9

Batching alone is ~2.2x end to end (170 s -> 77 s) and all but eliminates the read cost. The
write side turned out not to be SQLite at all — 74 of those 76 seconds were JSON
serialization, which is what the serializer upgrade fixes. For reference, raw SQLite against
the real CacheItem schema is ~12 s for the same rows in blocks of 1 000 and ~2 s in one
transaction.

This raises the Xrm.Json.Serialization floor from 1.2026.3.1 to 1.2026.9. NuGet resolves
lowest-applicable, so the floor has to move or downstream projects keep restoring the slow
version and get half the fix.

Contract notes

• GetRange omits keys it did not find rather than returning a placeholder, matching
  TryGetValue per key. Duplicate keys in the input collapse to one entry, in both the fast
  path and the fallback.
• The backend returns an empty buffer for a key it did not find, so absence and "stored an
  empty blob" are indistinguishable at that layer. GetRange treats both as a miss — the same
  as ContainsKey and TryGetValue already do.
• SetRange replaces existing keys like the indexer setter, and does not throw on a key that
  already exists.

Dependency graph (second commit, b7f9a67)

Taking Xrm.Json.Serialization 1.2026.9 let Visual Studio regenerate the binding redirects,
which narrowed the unification range added for MMS-8327 — VS only ever writes an
up-to-installed range, so SQLitePCLRaw.core and SQLitePCLRaw.batteries_v2 came back as
0.0.0.0-2.1.11.2622. That silently removes the headroom that keeps a stray 1.x or 3.x
reference from surfacing as the TypeLoadException this ticket exists to eliminate. Restored
to 0.0.0.0-3.0.0.0 in both app.config files. Only the test project's copy applies at
runtime — a library's app.config is inert, and the one next to the library is documentary
for consumers.

Three smaller corrections in the same commit:

• The nuspec dependency on Xrm.Json.Serialization reads 1.2026.9, matching how NuGet
  normalizes and restores it (1.2026.9.0 -> 1.2026.9).

• SQLitePCLRaw.provider.e_sqlite3 removed. Reading the assembly-reference tables out of
  the built DLLs gives the actual managed chain:

  SQLite-net.dll   -> batteries_v2, core
  batteries_v2.dll -> core, provider.dynamic_cdecl
  core.dll         -> (nothing)
  

  Nothing references provider.e_sqlite3 — it belongs to bundle_e_sqlite3, which this
  project does not use; bundle_green is what supplies the initialisation path. Removed from
  both packages.config files, both Reference blocks, and from the
  CopySQLitePclRawAssemblies target, whose literal (non-wildcard) Include would otherwise
  have failed the Copy task on a missing file.

• VS also added a System.ValueTuple redirect, which is a real dependency here. Kept.

Two things deliberately not changed:

• sqlite-net-pcl stays at 1.9.172. 1.11.285 publishes no .NET Framework dependency
  group at all; its .NETStandard2.0 group wants SQLitePCLRaw.core and
  provider.e_sqlite3 3.0.3 plus a new SourceGear.sqlite3 package. Taking it moves the
  assembly identity to 3.0.0.0, drops bundle_green from the graph, and invalidates every
  2.1.11.2622 redirect and Reference Version= in both this repo and JOE. That is the same
  class of failure as previously seen, so it belongs in its own ticket, after JOE is stable, with
  JOE's redirects updated in the same change.
• SQLitePCLRaw.lib.e_sqlite3 stays at 2.1.13 while core, bundle_green and the
  providers sit at 2.1.11. That is not skew: 2.1.13 is the CVE-2025-6965 floor, and the
  package ships native assets only — no managed assembly, so no binding identity to unify.

Tests

13 tests in BulkDictionaryTests: the interface fast path, the loop fallback, duplicate key
collapsing, missing keys, the 2 000-key chunk boundary, agreement with per-key TryGetValue,
CRM attribute round trips, replacement semantics, empty input and null argument rejection.

Suite: 62 tests, 0 failed (49 before), verified in both configurations after a clean
rebuild — Debug/AnyCPU in 1.60 s and x64/Release, which is what the nuspec packs from, in
2.38 s.

Both output trees carry exactly one version of each assembly, with no provider.e_sqlite3:

SQLite-net                           1.9.172.0
SQLitePCLRaw.batteries_v2            2.1.11.2622
SQLitePCLRaw.core                    2.1.11.2622
SQLitePCLRaw.provider.dynamic_cdecl  2.1.11.2622
e_sqlite3.dll                        (native, from lib.e_sqlite3 2.1.13)

The library's own bin correctly has no native e_sqlite3.dll — that reaches consumers
through the lib.e_sqlite3 nuget dependency, not the lib folder.

Known, pre-existing, not addressed here

Xrm.Persistent.Collections.Tests.csproj declares System.Buffers, Version=4.0.3.0 and
System.Runtime.CompilerServices.Unsafe, Version=6.0.0.0 in its Reference attributes while
the HintPaths point at packages whose assemblies are 4.0.5.0 and 6.0.3.0, so every build
emits MSB3277. The redirects cover it at runtime, which is why the suite is green. The main
project has the correct values. Test-project only, predates this branch.