metric sinks: SHOW, catalog visibility, and RBAC (SQL-572)

[mtabebe]

Problem:

A metric sink was invisible, mz_objects did not carry it, and there
was no way to read back the SQL that created it.

Solution:

SHOW METRIC SINKS [FROM <schema>] [IN CLUSTER <c>] [LIKE ...] lists
name, from, and cluster. SHOW [REDACTED] CREATE METRIC SINK replays
create_sql. Both require enable_metric_sink.

mz_internal.mz_metric_sinks exposes what the catalog knows about a
sink, shaped like mz_catalog.mz_sinks, and joins into mz_objects as
type metric-sink. It is a materialized view derived from
mz_catalog_raw. It carries owner_id, so a sink's owner is now
visible in the catalog and its ownership checks are testable.

The relation carries only the columns something reads. create_sql and
redacted_create_sql have no reader, and SHOW CREATE is how you get
the SQL back.

Testing:

• metric_sink.slt covers discovery and access control: the
  mz_metric_sinks row resolving to its FROM relation, cluster, schema,
  and owner, mz_objects and mz_show_all_objects membership, the three
  SHOW METRIC SINKS filters, the SHOW CREATE round-trip, the audit
  rows, and privileges.

• The restart platform check reads SHOW METRIC SINKS instead of
  probing with a CREATE expected to fail.

[def-]

QA LLM Review

1. HIGH -- new builtin index changes mz_indexes's fingerprint but reuses a migration step from the previous release cycle

src/adapter/src/catalog/open/builtin_schema_migration.rs:398

Adding mz_metric_sinks_ind changes mz_catalog.mz_indexes's SQL fingerprint, but the only mz_indexes replacement step is pinned at 26.39.0-dev.0, which now sorts below the release this change no longer ships in. Upgrading a v26.39.x environment to v26.40.x therefore skips the step, and environmentd aborts at catalog open with fingerprint mismatch for builtin ... mz_indexes.

Details

This branch was written against a tree whose workspace version was 26.39.0-dev.0, so reusing the existing step was correct then. main has since bumped to 26.40.0-dev.0, and v26.39.0-rc.1 is already tagged carrying mz_object_graph_edges_ind but not mz_metric_sinks_ind. After a rebase the step is one release cycle stale, exactly the hazard the NOTE a few steps above (builtin_schema_migration.rs:271) describes.

Mechanism, all in builtin_schema_migration.rs:

• plan_migration keeps only steps with version > source_version (line 778). semver orders 26.39.0-dev.0 < 26.39.0-rc.1 < 26.39.0, so any v26.39.x source drops it.
• The force_migration escape hatch that papers over dev-to-dev upgrades only triggers when the source version's pre-release starts with dev (line 671), so a release or rc source takes the version-filtered path.
• update_fingerprints then sees mz_indexes with a changed fingerprint and no migration, and panics (line 1209). Builtin::fingerprint() for a materialized view is its create_sql, and make_mz_indexes inlines the entire builtin-index set as VALUES precisely so that adding an index is a hard failure rather than silent drift (src/catalog/src/builtin.rs:1502).

Nothing on this PR will go red: fresh bootstraps never compare fingerprints, and the upgrade suites currently start from v26.38.1, from which the 26.39.0-dev.0 step still applies. The failure appears only once v26.39.0 becomes an upgrade source.

Fix: leave the existing step alone (it is historical, and covers only mz_object_graph_edges_ind) and add one at the workspace's current dev version:

        // Required because we added the `mz_metric_sinks_ind` builtin index.
        // make_mz_indexes inlines the builtin-index set as VALUES, so any add
        // or remove changes its SQL fingerprint and requires an explicit
        // replacement. See the NOTE above: this version must stay at the
        // workspace's current dev version until the change ships.
        MigrationStep::replacement(
            "26.40.0-dev.0",
            CatalogItemType::MaterializedView,
            MZ_CATALOG_SCHEMA,
            "mz_indexes",
        ),

The new mz_internal.mz_metric_sinks materialized view itself correctly needs no step: it has no durable mapping in an older catalog, and validate_migration_steps (line 763) would panic on a step naming it.