OP-1436 Sync load_demo_data.sql with the a118-a122 schema

[giuseppesorge]

What

sql/load_demo_data.sql is a self-contained mysqldump used to load a clean demo database. The step_a118–a122 migrations are on develop, but the demo dump was never regenerated for them:

• a118 — *_DELETED_BY / *_DELETED_DATE audit columns (admission, supplier, patient, user, usergroup)
• a119 — deleted-movement log tables (OH_MEDICALDSRSTOCKMOV_LOG, OH_MEDICALDSRSTOCKMOVWARD_LOG)
• a120 — user-related unique constraints (permissions, group-permission)
• a121 — DECIMAL(19,2) / INT precision on bills, prices and stock/medical quantities
• a122 — password-lease columns on OH_USER

As a result, creating a clean DB, loading load_demo_data.sql and starting the app fails at startup with:

Unknown column 'u1_0.us_deleted_by' in 'field list'

CI does not catch this because it builds the schema from the incremental step scripts, not from the demo dump — only the manual create docker db + load demo data flow is affected.

How

• Regenerated the affected tables via a MariaDB round-trip (load the current dump → run a118–a122 → dump the changed tables), so the demo dump schema matches the migration chain while existing rows keep real values. Only the 17 tables the migrations touch (plus the 2 new log tables) change; the other 47 are byte-identical.
• Cleared the demo admin user's US_LAST_LOGIN. With the OP-896 password-idle check (login refused when lastLogin + PASSWORDIDLE < now), the hardcoded US_LAST_LOGIN of 2026-01-15 idle-locks the admin account on any DB loaded after that window. NULL is the natural "never logged in" state for a fresh demo and skips the check, so it never goes stale.

Scope note

The bulk of the diff comes from a121: switching the quantity/amount columns to DECIMAL/INT reformats every bills / stock / medical data row. The startup crash itself only needs a118 + a122. Happy to narrow this PR to just the startup-fix subset if you'd prefer a smaller diff, or to keep the full a118–a122 sync — your call.

Testing

Loaded the regenerated load_demo_data.sql into a fresh MariaDB 10.6: loads with no errors, the previously-failing oh_user startup query succeeds, all demo rows preserved (e.g. 525 patients), and the admin account no longer idle-locks.

Fixes the startup failure reported on #1642.

[giuseppesorge]

This one is a decision rather than a conflict to resolve, so I stopped before touching it.

develop already carries the a118-a122 sync: comparing the two dumps, the 64 tables they have in common declare identical column lists. The part that actually mattered — the columns, whose absence breaks a clean demo database — is already in.

What is left of this PR is two tables the dump does not contain, oh_medicaldsrstockmov_log and oh_medicaldsrstockmovward_log, plus a few thousand lines of churn from regenerating the dump (timestamps and row order). Those two tables are created by step_a119, which is sourced from step_04, and load_demo_data.sql never drops them, so a clean demo database ends up with them (empty) either way. It is completeness, not correctness.

So either this PR is closed, or it is reduced to just adding those two tables, which would also make it reviewable. Happy to do whichever you prefer.