feat: scope .bzl edits to macro-produced rules via instantiation stack

[corypaik]

Problem

packageBzlSeeds (added in #365) attributes a loaded .bzl's content digest to every
target in every package that load()s it. That fixed the #259/#227 under-invalidation
(a macro edit that changed no rule attribute invalidated nothing), but it over-corrected:
editing one widely-load()ed rule .bzl now re-hashes every unrelated target in each
loading package — native rules, filegroups, source files — not just the targets that use
the rule.

In a repo where a single rule .bzl is loaded by hundreds of packages (each for one target),
a one-line edit to that .bzl reported ~130k impacted targets. In our case this was a
copybara target in each vendored directory, but would also have a similar effect for
any other lightweight config macro whose target nothing else in the package depends on
(e.g., a license target). With this fix our impacted set for that scenario is down to ~1k.

Change

Attribute each .bzl to the specific rules a macro produced, not the whole package.

RuleHasher.ruleBzlSeed builds a per-rule seed from the .bzl files in that rule's macro
instantiation stack (--proto:instantiation_stack), so a macro edit re-hashes only the
rules that macro created. Two signals combine to cover every edit:

• instantiation stack — the macro call chain (macros.bzl -> ... -> rule(...)). Covers
  macro edits, including a macro that wraps a native rule (which has no rule-definition
  digest), preserving Bazel Macro issue #259/:bazel-diff -- generate-hashes is not giving correct targets when changed something in build attribute .bzl file which imported in many BUILD files #227.
• $rule_implementation_hash — already emitted by Bazel as a synthetic rule attribute
  and already folded into the rule digest by BazelRule.digest. It is the transitive digest
  of the .bzl where the rule class is defined, so editing a rule's definition file (even
  in a different file than the macro that instantiates it) still invalidates its consumers.

Source-file target hashes drop the seed entirely (a source file's hash is its content).

When instantiation stacks are unavailable (older Bazel / the flag off), BuildGraphHasher
falls back to the existing per-package seed, so the #365 behavior is preserved there.

Coverage

edit	invalidates the consumer via
macro (same file as rule)	instantiation stack + impl hash
macro in a different file than the rule	instantiation stack
rule definition file (any file)	$rule_implementation_hash
macro wrapping a native rule (#259/#227)	instantiation stack
unrelated macro added elsewhere (#365)	— (correctly not impacted)
external rule (e.g. cc_library from @rules_cc)	impl-hash attribute + external dep-edge (unchanged)

Unrelated targets that merely share a package with a macro-produced target are no longer
swept in.

Cost

--proto:instantiation_stack adds ~2–7% to query-proto size on a macro-heavy graph. The
stack is already computed by Bazel (it backs macro-aware error messages), so there is no
meaningful query-time cost. It is on by default; the package-seed fallback keeps older
Bazel working.

Tests

New e2e fixtures + tests:

• rule_bzl_overtrigger — editing an existing widely-loaded rule .bzl impacts the target
  that uses it but not unrelated native targets in the same package.
• cross_file_macro_rule — a macro in one file loading a rule from another; editing
  either file impacts the consumer, and a sibling native target stays out.

The existing regression tests still pass: macro_invalidation (#259/#227) and
bzl_seed_overtrigger (#365).

[tinder-maxwellelliott]

Great fix! Thanks