V193: create extension_licensing tables that V100 silently skipped

[Mounika-2311]

Summary

Add Flyway migration V193 to create the extension_licenses, extension_usage, and extension_vendors tables. These tables back the Ciyex Workspace marketplace LicensingController and the JPA entity org.ciyex.ehr.licensing.entity.ExtensionLicense, but they do not exist in any environment that ran our earlier migrations — even though V100__extension_licensing.sql is present in the repo.

Why the tables are missing

There were two different V100 migrations over the lifetime of this repo:

1. Original V100__fix_system_menu_icon.sql — applied long ago in dev/stage/prod. Recorded in each cluster's flyway_schema_history with V100's checksum at that time.
2. Replacement V100__extension_licensing.sql — added in commit `f60fe9cb` ("Add extension licensing API for Ciyex Workspace marketplace", 2026-04-07). Commit `4f987424` ("fix: rename duplicate V100 flyway migration to V186", 2026-04-08) renamed the original menu-icon migration to V186 and left the licensing one as V100.

When pods later restarted, Flyway saw a checksum mismatch on V100, ran repair (called automatically on startup in this app), and silently rewrote the history row's checksum to match the new V100 file. repair does not execute the new migration content. As a result, V100 is recorded as "applied" with the licensing checksum, but the licensing tables were never created.

Why this surfaced now during the prod rollout

The currently running 0.1.2 pods in production are 22 days old. They were started before the marketplace code (`f60fe9cb`) was added, so their image content has no ExtensionLicense JPA entity and Hibernate never inspects extension_licenses. Promoting 0.1.4 pulled the new image, Hibernate ran with spring.jpa.hibernate.ddl-auto: validate (per application-prod.yml), and startup failed with:

```
SchemaManagementException: Schema validation: missing table [extension_licenses]
```

The deployment surface was protected only because k8s held the old pods serving while the new ones CrashLooped — but any restart of those old pods would have re-pulled the now-broken 0.1.2 tag and taken prod down.

What this migration does

V193 idempotently creates the three tables with the same DDL as the orphaned V100, using CREATE TABLE IF NOT EXISTS and CREATE INDEX IF NOT EXISTS so it is a no-op anywhere the original V100 did execute (e.g. fresh dev installs from scratch).

Test plan

• V193 applied successfully on prod cluster postgres during 0.1.4 rollout (pods reached 1/1 Ready).
• Confirm \\dt extension_licenses shows the table on dev / stage / DR.
• Smoke test the marketplace licensing endpoints: GET /api/licensing/{extId}, POST /api/licensing/{extId}/checkout, POST /api/licensing/webhook/stripe.
• Verify Hibernate startup with ddl-auto: validate no longer logs missing table warnings.