OP-1428 Persist the per-lot remaining quantity (LT_QTY)

[giuseppesorge]

OP-1428 (Persist the per-lot remaining quantity LT_QTY): https://openhospital.atlassian.net/browse/OP-1428

Follow-up of OP-1231. Persists LT_QTY (DECIMAL(19,2)) on OH_MEDICALDSRLOT as a mirror of the computed hospital-wide overall quantity, maintained by atomic per-operation deltas (as agreed on the issue: LT_QTY is the total remaining quantity; charge/discharge/delete operations only apply their own delta).

• LotIoOperationRepository.updateQuantity(code, delta) — atomic @Modifying increment (no optimistic-lock retries; LT_QTY is updatable = false so entity saves can't clobber it).
• Deltas wired into the four write paths: charge (MedicalStockIoOperations.updateStockQuantity, +qty; store→ward discharge is net-zero by design), delete-last-movement (MovBrowserManager, −qty when the lot survives), ward dispense/rectify (MedicalStockWardIoOperations, the delta mirrors the INT-truncated ward columns to stay consistent), delete-last-ward-movement (MovWardBrowserManager). Sign follows the type prefix ('+%') like the computed definition.
• sql/step_aXXX_persist_lot_quantity.sql: adds the column + backfills from movements/ward stock (consistent with the live JPQL). Migration tested on a real MariaDB 10.6 demo copy (values match the live computation).
• Unit tests across medicalstock/medicalstockward/medicalsinventory; full core suite green.
• The @Transient main-store/ward quantities stay as the validation/strip-empty source; getOverallQuantity() is unchanged.

Note: one deviation to flag — the io-level updateStockQuantity DISCHARGE branch decrements LT_QTY for the ward == null case (reachable via the io API / existing tests), where stock genuinely leaves the hospital.

Merge order: this must merge before OP-1427 (openhospital-core#1646), whose migration drops MDSRWRD_LT_ID_A that this backfill joins on.

[giuseppesorge]

@dbmalkovsky — good call, thanks. Synced load_demo_data.sql for this change (b0a3d3a2): added LT_QTY to oh_medicaldsrlot, back-filled from the demo stock movements. I regenerated it via a MariaDB round-trip of the migration (load the current demo dump → run the migration → mysqldump the changed tables) and verified it loads into a clean DB. I'll keep the demo dump in sync going forward.

[giuseppesorge]

@dbmalkovsky — good call, thanks. Synced load_demo_data.sql for this change (b0a3d3a2): added LT_QTY to oh_medicaldsrlot, back-filled from the demo stock movements. I regenerated it via a MariaDB round-trip of the migration (load the current demo dump → run the migration → mysqldump the changed tables) and verified it loads into a clean DB. I'll keep the demo dump in sync going forward.

[giuseppesorge]

Merged develop (a1b0d1e) to clear the conflict in sql/step_04_all_following_steps.sql: OP-1231 appended step_a123_add_lot_management_in_pharmacy.sql at the end of the file, so this branch's own source line now comes after it. Nothing else changed, and the branch's diff against develop is the same as before the merge.