Bump library projects from net8.0 to net10.0

[Kukks]

Summary

• Bumps the six NArk library projects from net8.0 to net10.0:
  • NArk, NArk.Abstractions, NArk.Core, NArk.Scratchpad, NArk.Storage.EfCore, NArk.Swaps
• Aligns library TFMs with test projects, which already target net10.0 per CLAUDE.md.
• .NET 8 is EOL November 2026; .NET 10 LTS is the long-term target.

Verification

• dotnet build NArk.sln -c Release → 0 errors
• dotnet test NArk.Tests → 418 / 418 passed

Test plan

• All NArk unit tests pass
• CI confirms green build across all jobs
• Downstream consumers (btcpay-arkade plugin, BTCPayApp) confirm continued compatibility

[arkanaai]

Review: Approve ✅

Straightforward TFM bump — 6 .csproj files, one line each, net8.0 → net10.0. No code changes.

What I checked

Cross-repo impact: The primary downstream consumer (btcpay-arkade) references these libraries via git submodule + ProjectReference, not NuGet. btcpay-arkade itself already targets net10.0 for all its own projects (BTCPayServer.Plugins.ArkPayServer.csproj, ConfigBuilder.csproj, NArk.E2E.Tests.csproj). The submodule copy of the NArk libraries is still on net8.0 — this PR fixes that mismatch. No breakage.

NuGet packaging: None of the 6 library projects declare PackageId, GeneratePackageOnBuild, or IsPackable=true. These aren't published NuGet packages, so dropping net8.0 doesn't break any external consumers.

Internal consistency: Test projects (NArk.Tests, NArk.Tests.End2End, NArk.Transport.GrpcClient.Tests) already target net10.0. This PR aligns the libraries to match.

Protocol-critical code: No protocol logic touched. Pure build config change — no VTXO, signing, forfeit, round, or exit path code affected.

Multi-targeting consideration: Given these are submodule-consumed (not NuGet), single-targeting net10.0 is fine. No need for net8.0;net10.0.

CI is still pending — confirm green before merge.

🤖 Reviewed by Arkana

[arkanaai]

Review: Approve ✅

Straightforward TFM bump — 6 .csproj files, one line each, net8.0 → net10.0. No code changes.

What I checked

Cross-repo impact: The primary downstream consumer (btcpay-arkade) references these libraries via git submodule + ProjectReference, not NuGet. btcpay-arkade itself already targets net10.0 for all its own projects (BTCPayServer.Plugins.ArkPayServer.csproj, ConfigBuilder.csproj, NArk.E2E.Tests.csproj). The submodule copy of the NArk libraries is still on net8.0 — this PR fixes that mismatch. No breakage.

NuGet packaging: None of the 6 library projects declare PackageId, GeneratePackageOnBuild, or IsPackable=true. These aren't published NuGet packages, so dropping net8.0 doesn't break any external consumers.

Internal consistency: Test projects (NArk.Tests, NArk.Tests.End2End, NArk.Transport.GrpcClient.Tests) already target net10.0. This PR aligns the libraries to match.

Protocol-critical code: No protocol logic touched. Pure build config change — no VTXO, signing, forfeit, round, or exit path code affected.

Multi-targeting consideration: Given these are submodule-consumed (not NuGet), single-targeting net10.0 is fine. No need for net8.0;net10.0.

CI is still pending — confirm green before merge.

🤖 Reviewed by Arkana

[Kukks]

E2E failure is a net10 LINQ-interpreter regression, not the TFM bump per se

The unit-test job is green; the E2E job hits a net10-specific expression-interpreter constraint:

System.ArgumentException: GenericArguments[1], 'System.ReadOnlySpan`1[NArk.Abstractions.Intents.ArkIntentState]',
on 'System.Linq.Expressions.Interpreter.FuncCallInstruction`2[T0,TRet]' violates the constraint of type parameter 'TRet'.
---> System.TypeLoadException: ...

In .NET 10 the TRet generic on EF Core's LINQ expression interpreter tightened to disallow ref structs. ReadOnlySpan<ArkIntentState> is a ref struct and on net8 the looser constraint accepted it — on net10 it crashes parameter extraction in the EF Core query pipeline.

Somewhere in the swap/intent query path (SwapsChanged handler region by the log timing) a ReadOnlySpan<ArkIntentState> is reaching the LINQ translator. The fix is to materialize the span before it enters the expression tree (e.g. .ToArray() or convert the predicate to a closed-over HashSet<ArkIntentState> lookup).

Build & Unit Tests pass on net10 cleanly — the TFM bump itself is sound. Marking this PR blocked on resolving the EF Core query pattern; the consumer side (BTCPayApp) continues consuming NArk at master (net8) without issue via compat shims.