✨ Migrate to eQuantic.Core.Data v5 contracts + per-major (net8/net10) packaging

[edgarmesquita]

v5 — migration to the eQuantic.Core.Data 5.1.0 contracts

This PR now also delivers what it originally listed as out-of-scope (Phases 3/4): the provider is
migrated to the eQuantic.Core.Data v5 contracts, and the parallel nuget.org version lines are
consolidated into an explicit scheme (see Packaging & versioning below). The Phase 0–2 record is kept
underneath for reference.

Contracts

• Reads are shaped through a single QueryOptions<TEntity> (filter / specification / includes /
  sortings / tracking / query-filter / tag / before-&-after customization) instead of
  Action<QueryableConfiguration> + a wall of overloads; paged reads return PagedResult<T> and counts
  return long.
• The unit-of-work type parameter is gone — IRepository<TEntity, TKey> — entities are constrained to
  IEntity<TKey> (no new()), and the write surface gains AddRangeAsync plus a
  CancellationToken on AddAsync.
• A QueryOptions → IQueryable translator applies the options in a defined order and stays server-side /
  EF-translatable (sortings included).
• The composed repositories now inherit read and delegate write, collapsing the old overload-delegation
  (~1,160 lines) to ~230 while keeping full sync + async read/write parity; the injected UnitOfWork is
  still never disposed by the repository (the C2 ownership fix is preserved).

SQL/Config rehomed to the provider layer

core-data v5 removed the Repository.Sql / Repository.Config abstractions. They are rehomed into the
Relational package under eQuantic.Core.Data.EntityFramework.Relational.Sql
(ISqlExecutor, IAsyncSqlExecutor, ISqlUnitOfWork, ParamValue, SqlConfiguration); the dead
QueryableConfiguration/ISqlRepository were dropped. The SQL-injection fix (S1) is preserved verbatim
— values still travel as DbParameters and are never interpolated into the command text or FromSqlRaw
template, and the parameterization regression test moved with them and still passes.

Packaging & versioning (resolves the "parallel version lines" question)

• Targets trimmed to net8.0 and net10.0 only — net6/net7/net9 removed.
• Per-major publish packages (what a consumer picks by runtime): base +
  SqlServer/PostgreSql/MySql/MongoDb at 8.2.0 (net8 / EF Core 8) and 10.1.0 (net10 / EF Core 10) —
  same PackageId across the 8 and 10 lines.
• Multi-framework lane kept in major 4 so it is never confused with a .NET version: the referenceable
  multi-target base is 4.5.0 and the new Relational package is 4.0.0.
• All packages reference eQuantic.Core.Data 5.1.0.

CI / release

• Both ci.yml and release.yml build matrices are pruned to the 12 surviving csprojs (and pick up the
  renamed MongoDb.Net8).
• The tag-triggered, environment-gated release flow is retained. Semantic-release is intentionally not
  adopted here: per-major (8.x / 10.x) versioning is incompatible with its single-version model.

Verification

• All 12 csprojs build clean on net8 and net10.
• 29 tests pass — base 8, SqlServer 18, MongoDb 3 — all on EF Core InMemory (no database required).

---

Earlier phases (0–2)

Context

Deep analysis of this repository (published on nuget.org for years) and of the eQuantic/core-data
contracts repository, followed by the implementation of Phase 1 (code fixes), Phase 0 (CI/release
pipeline) and Phase 2 (provider de-duplication). The full diagnosis, the 5-phase plan and the
contract-break analysis for a future v5.0.0 are in docs/IMPROVEMENT_PLAN.md.

Verification: all 6 packages build multi-target (base/Relational/SqlServer/PostgreSql/MySql on
net6–net10, MongoDb on net8–net10) and 28 tests pass. The placebo test (Assert.Pass()) was replaced
with real coverage (including a new MongoDb test project).

Phase 1 — Code fixes

Sev.	Finding	Fix
🔴	SQL injection (S1)	SqlExecutor interpolated values into the SQL text and passed the result to FromSqlRaw with no DbParameter — a real injection in ExecuteFunction/ExecuteProcedure across the 3 SQL providers. Now emits placeholders and the values travel as DbParameters. Tests prove a malicious value never reaches the generated SQL.
🟠	EXEC→CALL (P3)	PostgreSQL/MySQL used EXEC (T-SQL) copied from SqlServer — fails at runtime. Now use CALL.
🟠	Lost parameters (P4)	ExecuteQuery passed an IEnumerable as a single argument to FromSqlRaw — fixed with .ToArray().
🔴	DI crash (C3)	ISqlUnitOfWork was registered unconditionally → InvalidCastException for MongoDb. Now registered only when the implementation provides it.
🔴	Double-dispose (C1)	AsyncQueryableRepository shadowed _disposed and disposed the UnitOfWork twice.
🔴	MongoDb wrong database (P1/P6)	GetDatabase(_collectionName) used the collection name as the database name → deletes/updates silently against the wrong database. Now resolves the database from the DbContext's MongoOptionsExtension and throws instead of returning 0.
🔴	MongoDb silent corruption (P2)	UpdateDefinitionBuilder evaluated x => x.Count + 1 against a default instance and wrote the constant 1. Now rejects (throws on) update expressions that reference the entity.
🟠	All/Any ignored config (A1)	The sync variants discarded configuration; they now forward it.
🟠	Default key rejected (A2)	Get(0)/Guid.Empty threw ArgumentNullException. Now validates id is null.
🟠	Non-parameterized key (A4/M7)	GetFindByKeyExpression embedded the key value as a literal → query-cache pollution. Now parameterizes via a closure, caches PK metadata, and uses EF.Property (shadow keys).
🟠	Non-deterministic pagination (A5)	GetPaged/GetPagedAsync did Skip/Take without a guaranteed OrderBy. Now order by the primary key when there is no explicit ordering.
🟡	DI (M4)	AddRepository honours the configured lifetime, uses TryAdd and tolerates ReflectionTypeLoadException.
🟡	Async (M2)	ConfigureAwait(false) across 91 library awaits (base + 4 providers).

⚠️ Only behavioural change: C2 (UnitOfWork ownership)

The repository no longer disposes the injected UnitOfWork — the creator (DI container or caller) owns
the lifetime. Before, under DI, this disposed the shared DbContext out from under the other repositories
in the scope. Anyone who relied on disposing the repository to close a manually-created context must now
dispose the UnitOfWork/DbContext directly.

Note on M8: the plan finding (remove Where(_ => true) in GetAllAsync) was wrong — that Where
is load-bearing. Documented in code + a regression test; nothing removed.

Phase 0 — CI/release

Finding	Fix
Q1 accidental publishing	on: [push] published to nuget.org on every push to any branch. CI split into ci.yml (build + test, never publishes) and release.yml (only on a vX.Y.Z tag, publishes behind a nuget-release GitHub Environment).
Q2 no tests in CI	ci.yml now runs dotnet test on the 3 test projects.
Q3 dated pipeline	Actions updated (v3→v4), ubuntu-latest, NuGet cache, -p:ContinuousIntegrationBuild=true.
Q4 unpinned SDK	global.json pinning the SDK.
PK7 dead MSBump	Removed build/MSBump.props (circular import), build/MSBump.targets (missing task) and build/Directory.Build.targets (never imported).
PK2 graph bug	MySql.Net10.csproj referenced the Net9 core instead of Net10.

Phase 2 — Provider de-duplication

Extracted the shared relational implementation into a new package,
eQuantic.Core.Data.EntityFramework.Relational, referenced by the 3 SQL providers.

• The SqlServer/PostgreSql/MySql SqlExecutor, UnitOfWork, Set and ExpressionConverter were
  near-identical copies. They now live once in the shared package. Each provider keeps thin Set and
  UnitOfWork<TDbContext> subclasses plus DefaultUnitOfWork, so the consumer-facing types stay in their
  namespaces. ~2,200 fewer lines of duplicated source (3,029 removed / 799 added).
• The only genuine dialect difference (stored procedures: EXEC on SQL Server, ANSI CALL elsewhere) is a
  single BuildProcedureSql virtual, overridden only by SQL Server — the copy-paste that let EXEC/CALL
  diverge is gone.
• Why a new package (not the base package or linked source): the base package must not pull
  Microsoft.EntityFrameworkCore.Relational into MongoDb consumers, and linked source would collide when a
  consumer references two providers. A separate multi-target assembly is the only clean option; see the plan
  for the full reasoning.
• MySql's per-framework variants are realigned to the multi-target base project (matching
  SqlServer/PostgreSql) so the shared project does not pull a second copy of the base assembly.

Minor source break: the implementation-only public types SqlExecutor, the non-generic UnitOfWork
and SqlConfigurationExtensions move to the Relational namespace, and GetEntityByIdSpecification now
takes RelationalUnitOfWork. The consumer-facing DefaultUnitOfWork / UnitOfWork<TDbContext> /
Set<TEntity> are unchanged.

⚠️ Needs a maintainer with GitHub access

1. Nothing publishes automatically until a tag exists — git tag vX.Y.Z && git push origin vX.Y.Z.
2. The nuget-release Environment has no protection until configured in Settings → Environments
   (this session cannot configure it). Without a required reviewer there, the gate is only nominal.
3. The new Relational package (version 1.0.0) is a new published package the SQL providers now
   depend on; its versioning must join whichever scheme is chosen in Part IV.

Out of scope (larger phases, awaiting a chosen approach)

• Phases 3/4 — v5.0.0 of the contracts (eQuantic.Core.Data) and consolidation of the parallel version
  lines on nuget.org (the decision that also blocks MinVer adoption).
• P2 (evolution) — support entity-referencing updates via $inc/pipeline instead of rejecting them.

[sonarqubecloud]

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud