Bazel 7.1.1 and nixpkgs GHC 9.8.2 produce dynamically linked haskell_cabal_binary's

Describe the bug
I am seeing bazel 7.1.1 and a nixpkgs GHC 9.8.2 produce dynamically linked binaries for haskell_cabal_binary rules, via stack_snapshot. haskell_binary rules still produce statically linked binaries. The bazel dependencies for the dynamically linked binary aren't set up correctly, and will be cleaned up and not replaced when the haskell_cabal_binary target is rebuilt.

To Reproduce
https://nas.kylebutt.page/~kyle/bazel-hls-reproduce.tar.xz has a complete reproduction. There are two local_repository rules in the WORKSPACE that have comments indicating the git hashes that are checked out to reproduce the issue.

Expected behavior
rules_haskell should either produce a binary that is statically linked against the haskell dependencies, or it should tell bazel about the dynamic dependencies so that building it causes bazel to populate the library dependencies

Environment

• Linux, Ubuntu 22.04
• Bazel version: 7.1.1
• Version of the rules: git rev: bf2e6cdc6eb8863f5759b334ca9291e0d8f0584a

Additional context
The build time can likely be reduced by building something with fewer dependencies, like ghcide or hie-bios. They should still show the same static/dynamic linking issue.

I verified that the issue isn't reproducible with bazel 6.5.0. I can work around this bug, but I need the better tree-artifact handling of bazel 7+ for a different issue elsewhere in my repository.

Start with the linked reproduction archive and inspect the WORKSPACE local_repository rules and their checked-out git hashes. Compare the haskell_cabal_binary and haskell_binary builds through stack_snapshot on Bazel 7.1.1, using a smaller ghcide or hie-bios target if needed. Done means the output is statically linked or Bazel correctly tracks and restores its dynamic dependencies.