Asynchronous materialization of samples view

[XingY]

Rationale

On server start or after sample designer update, the first request to load the sample grid for a large sample type triggers a synchronous full table materialization, which can take a long time if the number of sample rows is large. If the user navigates away before it completes, the HTTP request is cancelled mid-flight, aborting the SELECT INTO. The materialized view is never populated — subsequent visits repeat the same blocking behavior indefinitely.

This change decouples view population from the request. When the materialized view is not ready (never built, or stale due to pending incremental updates), the request falls back immediately to direct JOINs and submits a background rebuild. The background task runs to completion regardless of user navigation, so the next visit uses the fast materialized path.

Related Pull Requests

Changes

• Added a "Clear Materialized Views" action to clear all materialized samples view for troubleshooting.
• ExpMaterialTableImpl: replaced the synchronous getMaterializedSQL() call with the async-aware path.