Add Reconcile RCA dashboard

[m-abulazm]

A new Lakeview dashboard (rca_metrics) for root-cause analysis of reconcile runs. Replaces the legacy reconciliation_metrics dashboard.

Two sections:

• Recon Jobs: Jobs Summary + Run Details tables
• Table Health: KPI counters, Latest Run per Table (with failing columns joined from column_metrics), Runs Over Time and Failed Rows Over Time grouped bars, Failures by Table + Successes by Table pies

Data model enhancement: rework the nested reconciliation data model for
better usability and queryability.

Remove the LSQL library dependency from the dashboard deployment path.

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 47 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.32%. Comparing base (55406fe) to head (3b97725).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...abricks/labs/lakebridge/reconcile/recon_capture.py	25.00%	39 Missing ⚠️
...databricks/labs/lakebridge/deployment/dashboard.py	82.85%	3 Missing and 3 partials ⚠️
...ridge/reconcile/trigger_recon_aggregate_service.py	0.00%	1 Missing ⚠️
...labs/lakebridge/reconcile/trigger_recon_service.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2496      +/-   ##
==========================================
- Coverage   69.43%   69.32%   -0.12%     
==========================================
  Files         106      106              
  Lines        9576     9623      +47     
  Branches     1056     1060       +4     
==========================================
+ Hits         6649     6671      +22     
- Misses       2729     2752      +23     
- Partials      198      200       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

✅ 177/177 passed, 8 flaky, 2 skipped, 2h16m57s total

Flaky tests:

• 🤪 test_installs_and_runs_local_bladebridge (12.586s)
• 🤪 test_installs_and_runs_pypi_bladebridge (22.19s)
• 🤪 test_transpiles_informatica_to_sparksql_non_interactive[True] (23.563s)
• 🤪 test_transpiles_informatica_to_sparksql (25.525s)
• 🤪 test_transpile_teradata_sql_non_interactive[True] (5.956s)
• 🤪 test_transpile_teradata_sql_non_interactive[False] (8.089s)
• 🤪 test_transpile_teradata_sql (26.994s)
• 🤪 test_transpiles_informatica_to_sparksql_non_interactive[False] (21.146s)

_{Running from acceptance #5014}

[BesikiML]

1. Migration path lacks automated test
   Can we add at least one integration test that:

• Creates a legacy details table with data ARRAY<MAP<...>>
• Runs the upgrade
• Asserts row counts and a sample mismatch row in the new schema

2. *_backup tables are never dropped
   Migration renames old tables to details_backup / aggregate_details_backup but never cleans them up. Over time this doubles storage for every upgraded workspace.

Is that intentional for rollback? If so, worth documenting in the PR body. If not, consider a follow-up or optional cleanup step.

3. Removed Lakeview retry logic
   The old DashboardDeployment had @Retried(on=[InternalError, DeadlineExceeded], timeout=3min) around dashboard create/update. The new lakeview.create / update / publish path has no retries.

Was this intentional? Transient Lakeview failures were a known issue (per old comments). Worth keeping retries on the new SDK calls if flakiness still happens in CI/deploy.

4. Naive catalog/schema substitution (low)
   raw = raw.replace("remorph.reconcile.", f"{config.catalog}.{config.schema}.")
   Works for the placeholder convention, but a blind string replace could corrupt unrelated occurrences inside the 142KB JSON. Safer long-term: structured substitution or a more constrained token (e.g. {{CATALOG}}.{{SCHEMA}}.).

5. Minor test inconsistency
   Most recon capture tests use the ws fixture; test_store_run_context still uses mock_workspace_client. Not blocking, but inconsistent with the direction from test(integration): use pytester ws fixture in reconcile integration tests #2521.

[bishwajit-db]

Re point 2 (*_backup tables): keeping them is intentional. The migration is a one-way, destructive transformation of user data (rename original, recreate, backfill), so the original tables are preserved as *_backup to serve as a rollback path in case the transformed data turns out wrong for some edge case. We did not want an upgrade step to silently delete user data, and the upgrade log explicitly points at the backup table so admins know where the raw rows live. Dropping the backups is left to the workspace admin once the migrated tables are verified; an optional cleanup step can be added as a follow-up if there is demand. Will make sure this is called out in the PR description as well.

Points 1, 3 and 5 will be addressed in upcoming commits on this PR.

[BesikiML]

LGTM