Switches the database from SQL Server to MariaDB

The target Pi only has MariaDB, and SQL Server has no ARM64 build at
all - not a config problem, a real gap discovered during deployment
setup. Swapped the EF Core provider, regenerated every migration,
updated connection strings and the backup script everywhere they
appear.

Took two tries to land on a provider that actually works: Pomelo
builds fine against this project's EF Core 10 packages but fails at
runtime (it's compiled against 9's internal API surface, which moved
in 10 wherever Identity/DataProtection force the newer packages).
Oracle's official provider builds and migrates fine but has a real
MariaDB bug in its own migration-lock code, reproduced against a live
database. Kept Oracle's provider and worked around just that one
broken method - everything else it does is correct - rather than
give up more of the stack to chase a workaround.

Verified against a real local MariaDB end to end: all three
migrations applied, both hosts start clean, full suite still green.

aidlc-docs/features/gitea-deployment-workflow/audit.md

@@ -1345,3 +1345,14 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an
 **Context**: OPERATIONS — Deployment Setup, configuration guidance clarified before final approval
 
 ---
+## Database Provider Migration — SQL Server to MariaDB
+
+**Timestamp**: 2026-07-29T00:00:00Z
+
+**User Input**: "Op de Pi draait op dit moment alleen MariaDB en geen mssql. Maakt dat uit?" ... "Nee, geen andere machine, maar kan het misschien met een podman container geregeld worden? Die draait wel op die machine" ... "De beoogde productieomgeving zal ook MariaDB hebben (mijnhostingpartner.nl) en de websites zullen niet mega groot worden dus ik denk dat voor performance MAriaDB ook prima is. Laten we optie 1 doen met MariaDB. Ik heb de lokale connection string aangepast. Die zou moeten werken. Dus als het lukt mag je meteen de migraties mogen runnen als dat nodig is" ... "In deze pull request: https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/pull/2017 [...] Als je dat kan controleren dan zouden we door kunnen" ... "Ja, probeer die override"
+
+**AI Response**: "Identified that SQL Server has no ARM64 build and Azure SQL Edge (the former ARM path) is retired, explained the tradeoffs (remote SQL Server, QEMU emulation, or switching to MariaDB), user chose MariaDB. Swapped Microsoft.EntityFrameworkCore.SqlServer for MySql.EntityFrameworkCore across Core.csproj and the 3 UseSqlServer call sites, regenerated all migrations, updated connection strings and README/deployment docs. Tried Pomelo per the user's PR link — confirmed it restores/builds against EF Core 10.0.9 (matching the maintainer's claim) but fails at runtime with a MissingMethodException, since this project's Identity/DataProtection EF Core integration packages force EF Core 10 packages regardless of Pomelo's own 9.x dependency range. Reverted to Oracle's provider, which then surfaced a second, independent bug: AcquireDatabaseLock() throws InvalidCastException against real MariaDB (GET_LOCK() returns NULL where Oracle's code expects an integer). Implemented NonLockingMySQLHistoryRepository as a targeted workaround (constructs Oracle's internal history repository via reflection, forwards everything except the two lock methods). Verified end to end: all 3 migrations applied to the user's real local MariaDB, both hosts (Api and Api.Slave) start cleanly against it, full 372-test backend suite still green. Corrected ASM-04 in requirements.md and recorded the full saga in aidlc-state.md."
+
+**Context**: OPERATIONS — Deployment Setup revealed a genuine Construction-phase technology gap; resolved with application code changes (not just documentation), verified against a real database
+
+---