Adopt upstream #2187: migrate to Bazel 7.3.2 + bzlmod (fold into next upstream sync)

[ihistand]

Context

Upstream merged dataform-co/dataform#2187 — "Migrate to bazel 7.3.2" (merged 2026-06-16, labeled Internal Cleanup). It's a build-infrastructure migration with no user-facing change.

What it does upstream:

• Bumps .bazelversion 5.4.0 → 7.3.2
• Introduces bzlmod (MODULE.bazel + MODULE.bazel.lock) for deps that support it (bazel_skylib 1.7.1, protobuf 27.3, rules_go 0.49.0, gazelle 0.37.0, custom gcloud SDK module extension)
• Keeps WORKSPACE only for the deprecated build_bazel_rules_nodejs rules
• Reworks webpack configs, the ts_library / ts_proto_library macros, proto BUILD (strip_import_prefix, module_name/module_root), and credential/runfiles path resolution to handle bzlmod's workspace rename

Current sqlanvil state

• .bazelversion = 5.4.0
• WORKSPACE-only, no MODULE.bazel
• Workspace named sa (upstream's is df)
• Builds run via scripts/docker-bazel (native macOS bazel currently broken: wrapped_clang/dyld LC_UUID error)

Plan: do this as part of the next upstream sync, not standalone

Rationale:

1. No user benefit — internal cleanup; current build works.
2. Invasive + sqlanvil-specific risk — the upstream PR hardcodes the df / _main workspace names throughout (webpack entry/alias, ts_library module_name, ts_proto_library amd_name/workspace_name fallback, runfiles credential path, proto module_name = "df/protos/ts"). Our workspace is sa, so it can't be applied verbatim — every one of those paths needs adapting to sa (or to the bzlmod _main).
3. The diff arrives at sync time anyway — main is published and we take upstream via merge, not rebase, so these 15 files land in the next sync diff. Reconciling them during that merge is strictly less work than doing it now and re-reconciling later.

Things to verify when we do it

• macOS native-toolchain angle: check whether Bazel 7.3.2's newer Apple CC toolchain fixes our native wrapped_clang/dyld breakage. If it does, we can drop the docker-bazel workaround — this is the one outcome that would justify doing it early. Verify, don't assume.
• Adapt all df / _main workspace-name references to sa.
• Confirm the :package_tar publish targets still produce a correctly-versioned tarball after the migration.
• Bazel 8 removes WORKSPACE entirely, so bzlmod is eventually mandatory if we keep pulling upstream — this is a "when," not "if."

Files touched upstream (15)

.bazelrc, .bazelversion, .github/workflows/test.yaml, MODULE.bazel (new), MODULE.bazel.lock (new), WORKSPACE, cli/index_test_base.ts, cloudbuild-publish.yaml, cloudbuild-test.yaml, packages/@dataform/core/webpack.config.js, packages/sample-extension/webpack.config.js, protos/BUILD, tools/gcloud/extensions.bzl (new), tools/ts_library.bzl, tools/ts_proto_library.bzl

References

• Upstream PR: Migrate to bazel 7.3.2 dataform-co/dataform#2187