fix: use merge_all() to avoid O(n)-depth runfiles NestedSet nesting

[honnix]

Summary

• Replace sequential runfiles.merge() calls in loops with collecting into a list + single merge_all() call in both multirun.bzl and command.bzl
• This changes the NestedSet depth from O(n) to O(1), preventing StackOverflowError in large multirun targets

Problem

When a multirun target has many commands (e.g. 1000+), the current code calls runfiles.merge() in a loop:

for command in ctx.attr.commands:
    runfiles = runfiles.merge(default_info.default_runfiles)

Each merge() wraps the previous result as a transitive child, creating a linear chain of NestedSets with depth proportional to the number of commands. When Bazel later fingerprints this structure via the recursive NestedSetFingerprintCache.addToFingerprint, it overflows the JVM stack.

We hit this as a java.lang.StackOverflowError (1022 recursive frames deep) when upgrading to Bazel 9.1.1 in a monorepo with ~1000 deploy targets aggregated via a single multirun target. The crash is in Bazel's internal NestedSet fingerprinting:

FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.StackOverflowError
	at c.g.d.b.l.collect.nestedset.DigestMap.readDigest(DigestMap.java:69)
	at c.g.d.b.l.collect.nestedset.NestedSetFingerprintCache.addToFingerprint(NestedSetFingerprintCache.java:106)
	at c.g.d.b.l.collect.nestedset.NestedSetFingerprintCache.addToFingerprint(NestedSetFingerprintCache.java:109)
	... (1022 frames)

Fix

Collect all runfiles objects into a flat list, then call merge_all() once. This produces a shallow NestedSet tree regardless of the number of commands.

merge_all() has been available since Bazel 5.x.

Test plan

• Existing tests continue to pass
• Verified against a monorepo with 1000+ commands that previously hit StackOverflowError

🤖 Generated with Claude Code

[keith]

that's a lot of runfiles! thanks!