Feat/app UI i18n insights contracts (#1262)

## Changes

This PR adds substantially richer
authoring UI, and overhauls the deployment story. At a high level:


**Data-contract & AI rule generation**
- Import ODCS v3.x data contracts and generate DQX rules (predefined,
property-based, and natural-language) via a new `contract_rules_service`
and
  `/v1/contract` route, including a dedicated "from contract" UI.
- Natural-language (`type: text`) expectations are generated through the
app's
ChatDatabricks Foundation Model path (no dspy/Spark needed
in-container).
- Reference-table checks (`foreign_key`, `has_valid_schema`) are now
authored in
the single-table editor with a table picker; schema-validation gets its
own
editor and mutual-exclusion handling for `expected_schema` vs
`ref_table`.

**UI features**
- Internationalization (English, Spanish, Italian, Portuguese-BR) with a
  language selector and locale-parity test.
- Insights dashboard is now hosted persistently so the embedded Lakeview
iframe
  no longer reloads on every navigation; expandable labels UI; component
  reorganisation (`apx/` → `layout/`); regenerated API client (orval).

**Deployment & docs**
- Updated DEPLOYMENT.md / DEVELOPMENT.md (CLI v1.4.0+ gate, one-button
  `postgres_roles`, bind workflow) and removed duplicated content.


### Linked issues
<!-- DOC: Link issue with a keyword: close, closes, closed, fix, fixes,
fixed, resolve, resolves, resolved. See
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
-->

Resolves #..

### Tests
<!-- How is this tested? Please see the checklist below and also
describe any other relevant tests -->

Added backend unit suites for the Lakebase executor, Postgres/Delta
migration
runners, contract rule generation, discovery DDL, dry-run dispatch, app
scheduler lease, quarantine filtering, lint policy, and i18n locale
parity.
`make app-test` (658 passing) and `make test` (1160 passing) are green,
along
with `make fmt` and `make app-check`.

- [x] manually tested
- [x] added unit tests
- [ ] added integration tests
- [ ] added end-to-end tests
- [ ] added performance tests

### Documentation and Demos
<!-- Any user facing changes require documentation and demos update -->

- [ ] added/updated demos
- [x] added/updated docs
- [x] added/updated agent skills

---------

Co-authored-by: Marcin Wojtyczka <marcin.wojtyczka@databricks.com>

Author: berrybluecode

Makefile

@@ -179,6 +179,33 @@ app-test: ## Run app backend pytest suite (K=<expr> filter, COV=1 for coverage)
 
 ##@ App deploy (require PROFILE=<databricks-profile>; most also need TARGET=<bundle-target>)
 
+# Minimum Databricks CLI version required to deploy. The ``postgres_roles``
+# resource in ``app/databricks.yml`` (one-button Lakebase provisioning) was
+# added in CLI v1.4.0 (https://github.com/databricks/cli/pull/5467); older
+# CLIs reject the unknown field at ``bundle validate`` with a confusing
+# error deep inside the deploy. Fail fast here with an actionable message.
+DATABRICKS_MIN_VERSION := 1.4.0
+
+# Preflight: assert the CLI exists and is new enough. Used as a prerequisite
+# of app-deploy / app-bind so the version gate runs before any build or
+# network call. The sort -V trick: the smallest of {MIN, installed} equals
+# MIN exactly when installed >= MIN (handles 1.10 > 1.4 unlike a string sort).
+app-check-cli: ## Verify the Databricks CLI meets the minimum version for deploy
+	@command -v databricks >/dev/null 2>&1 || \
+	  { echo "ERROR: 'databricks' CLI not found on PATH. Install: https://docs.databricks.com/dev-tools/cli/install.html"; exit 1; }
+	@ver=$$(databricks --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1); \
+	  if [ -z "$$ver" ]; then \
+	    echo "ERROR: could not parse a version from 'databricks --version'."; exit 1; \
+	  fi; \
+	  if [ "$$(printf '%s\n%s\n' "$(DATABRICKS_MIN_VERSION)" "$$ver" | sort -V | head -1)" != "$(DATABRICKS_MIN_VERSION)" ]; then \
+	    echo "ERROR: Databricks CLI v$$ver is too old; v$(DATABRICKS_MIN_VERSION)+ is required to deploy DQX Studio."; \
+	    echo "       app/databricks.yml uses the 'postgres_roles' resource (one-button Lakebase),"; \
+	    echo "       which older CLIs reject at 'bundle validate' with an unknown-field error."; \
+	    echo "       Upgrade:  brew upgrade databricks   (or https://docs.databricks.com/dev-tools/cli/install.html)"; \
+	    exit 1; \
+	  fi; \
+	  echo "✓ Databricks CLI v$$ver (>= $(DATABRICKS_MIN_VERSION))"
+
 # Grant Unity Catalog permissions after bundle deploy.
 #
 # Usage: make app-grant-permissions PROFILE=my-profile
@@ -216,7 +243,7 @@ app-grant-permissions: ## Run post-deploy GRANTs (called by app-deploy; standalo
 # to ``make app-deploy`` — the bind step reads the resolved bundle
 # variables to know which instance/schema name to bind to, so an
 # override applied only at deploy time would bind the wrong resource.
-app-bind: ## Adopt pre-existing UC schemas / volume / Lakebase into bundle (run ONCE per workspace)
+app-bind: app-check-cli ## Adopt pre-existing UC schemas / volume / Lakebase into bundle (run ONCE per workspace)
 	@test -n "$(PROFILE)" || (echo "Usage: make app-bind PROFILE=<databricks-profile> TARGET=<bundle-target>"; exit 1)
 	@test -n "$(TARGET)" || (echo "Usage: make app-bind PROFILE=<databricks-profile> TARGET=<bundle-target>"; exit 1)
 	app/scripts/bind_resources.sh -p $(PROFILE) -t $(TARGET) $(if $(BUNDLE_VARS),-- $(BUNDLE_VARS))
@@ -245,10 +272,17 @@ app-bind: ## Adopt pre-existing UC schemas / volume / Lakebase into bundle (run
 # after a manual delete (the deploy errors out with "Instance name is
 # not unique" otherwise). Per-deploy CLI overrides keep ``databricks.yml``
 # clean.
-app-deploy: app-build ## Build, deploy bundle, grant permissions, and start app
+#
+# FORCE=1 appends ``--force`` to ``bundle deploy``. Use it when the deploy
+# aborts because a resource was modified in the workspace UI since the last
+# deploy (e.g. "dashboard ... has been modified remotely") — ``--force``
+# overwrites the remote copy with the bundle's local definition. This DROPS
+# any in-UI edits, so only set it once you've confirmed the local version is
+# the one you want to ship.
+app-deploy: app-check-cli app-build ## Build, deploy bundle, grant permissions, and start app (FORCE=1 to overwrite remote edits)
 	@test -n "$(PROFILE)" || (echo "Usage: make app-deploy PROFILE=<databricks-profile> TARGET=<bundle-target>"; exit 1)
 	@test -n "$(TARGET)" || (echo "Usage: make app-deploy PROFILE=<databricks-profile> TARGET=<bundle-target>"; exit 1)
-	cd app && databricks bundle deploy -p $(PROFILE) -t $(TARGET) $(BUNDLE_VARS)
+	cd app && databricks bundle deploy -p $(PROFILE) -t $(TARGET) $(if $(FORCE),--force) $(BUNDLE_VARS)
 	app/scripts/post_deploy_grants.sh -p $(PROFILE) -t $(TARGET) $(if $(BUNDLE_VARS),-- $(BUNDLE_VARS))
 	cd app && databricks bundle run $(APP_NAME) -p $(PROFILE) -t $(TARGET) $(BUNDLE_VARS)
 
@@ -294,4 +328,4 @@ fork-sync: ## Mirror a fork PR to a branch in the main repo for full CI (PR=<num
 	./.github/scripts/fork-sync-pr.sh $(PR)
 
 .DEFAULT: all
-.PHONY: help all clean dev lint fmt test integration e2e perf anomaly coverage combine-coverage docs-build docs-serve-dev docs-install docs-serve docs-clean app-install app-build app-start-dev app-stop-dev app-regen-api app-check app-test app-grant-permissions app-bind app-deploy fork-sync build lock-dependencies lock-app-dependencies
+.PHONY: help all clean dev lint fmt test integration e2e perf anomaly coverage combine-coverage docs-build docs-serve-dev docs-install docs-serve docs-clean app-install app-build app-start-dev app-stop-dev app-regen-api app-check app-test app-check-cli app-grant-permissions app-bind app-deploy fork-sync build lock-dependencies lock-app-dependencies

SECURITY.md

@@ -0,0 +1,45 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+**Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.**
+
+If you believe you've found a security vulnerability in DQX (the library, the CLI, or the DQX Studio web application), report it privately through one of the following channels:
+
+1. **GitHub Security Advisories (preferred)** — open a private advisory on the [DQX repository](https://github.com/databrickslabs/dqx/security/advisories/new). This keeps the report confidential until a fix is released.
+2. **Email** — if you cannot use GitHub Security Advisories, contact the Databricks Labs maintainers at [labs-oss@databricks.com](mailto:labs-oss@databricks.com) with `DQX SECURITY` in the subject line.
+
+### What to include
+
+To help us triage quickly, please include as much of the following as you can:
+
+- A description of the issue and its potential impact.
+- Steps to reproduce (proof-of-concept code, sample input, or a minimal repro repo).
+- The affected version(s) of DQX and, if relevant, the Databricks Runtime version.
+- Any mitigations or workarounds you have identified.
+
+We will acknowledge receipt within **5 business days** and provide a more detailed response within **10 business days** indicating our next steps. We aim to patch confirmed vulnerabilities in a timely manner and will coordinate disclosure with the reporter.
+
+## Supported Versions
+
+Security fixes are only guaranteed for the **latest minor release** on the [`main` branch](https://github.com/databrickslabs/dqx) and published on [PyPI](https://pypi.org/project/databricks-labs-dqx/). Please upgrade to the latest release before reporting an issue when possible.
+
+## Scope
+
+The following are in scope:
+
+- The `databricks-labs-dqx` Python library and CLI.
+- The DQX Studio web application under `app/` (FastAPI backend + React frontend).
+- The task-runner Databricks Job under `app/tasks/`.
+- Example code in `demos/` (informational only — reports welcome but low priority).
+
+Out of scope:
+
+- Vulnerabilities in third-party dependencies that are better reported upstream.
+- Issues requiring a privileged user (e.g., workspace admin) to already be compromised.
+- Denial-of-service resulting from reasonable use of Databricks platform limits.
+
+## Disclosure Policy
+
+- We follow a **coordinated disclosure** process and will credit reporters in release notes unless they prefer anonymity.
+- We request that reporters give us a reasonable window (typically 90 days) to issue a fix before any public disclosure.

app/CLAUDE.md

@@ -32,7 +32,17 @@ RBAC is enforced — routes use `require_role(*roles)` from `backend/dependencie
 2. **Business user adjusts existing rules** — load → edit → optional dry-run → save (creates new version + approval request)
 3. **Engineer reviews and approves rules** — review GUI/YAML → optional dry-run → configure checks storage → approve → export to Delta table
 4. **Engineer generates rules via profiler** — select table → configure sampling → run profiler → review candidates → save
-5. **User browses and discovers rules** — filter by table/domain/owner/status → view versions → compare → import/export
+5. **Engineer pins a schema contract** — single-table editor → pick target table → add a `has_valid_schema` check → expected schema as DDL or reference table → strict/compatible mode → dry-run → save
+6. **Data product owner imports rules** — Import rules page → pick **From DQX YAML** or **From data contract** tab → review preview → save drafts
+7. **User browses and discovers rules** — filter by table/domain/owner/status → view versions → compare → import/export
+
+### Synthetic FQN convention (`__sql_check__/<name>`)
+
+Per-table rules carry a real `table_fqn`. **Cross-table SQL checks** are the only rules without a single home table, so they use the synthetic prefix `__sql_check__/<name>` and bucket under the **Cross-table rules** group in the UI catalog and edit-router. The runner reads their query body from `arguments.sql_query` and builds the input view from it (SQL fast-path, `is_sql_check=True`).
+
+Reference checks such as `has_valid_schema` and `foreign_key` are **per-table** — they carry a real `table_fqn`, are authored/edited in the single-table editor, group under their target table, and run through the standard row-level engine via the normal `create_view(table_fqn)` path. They are *not* synthetic and need no special dispatch.
+
+The cross-table dispatch lives in `backend/routes/v1/dryrun.py` and `backend/services/scheduler_service.py`. If you add another table-less rule kind, follow the synthetic-FQN convention and update both dispatchers in lock-step.
 
 ## Internal Storage