Imported dynamic Swift frameworks are not scanned for required Swift dylibs

When packaging Swift runtime libraries, `rules_apple` uses `swift-stdlib-tool` to scan Mach-O binaries and determine which Swift runtime dylibs must be bundled. However, the scan currently only includes the main binary and any binaries propagated through `_AppleSwiftDylibsInfo` ([code](https://github.com/bazelbuild/rules_apple/blob/61a2124e19c4babd51810985ac81ae227d71abe1/apple/internal/partials/swift_dylibs.bzl#L132-L154)).

Prebuilt dynamic frameworks are instead represented via `AppleFrameworkImportInfo`, and their embedded Mach-O binaries are not included in the `swift-stdlib-tool --scan-executable` inputs.

As a result, Swift runtime dependencies introduced only by imported frameworks are missed. For example, an app may link against a prebuilt Swift framework whose binary contains a dependency such as:
```
@rpath/libswiftCompatibilitySpan.dylib
```

If the app binary itself does not reference this dylib, scanning only the app executable will not detect it, even though it is required at runtime. This will cause app crash on launch.

Start in apple/internal/partials/swift_dylibs.bzl around lines 132-154 and trace how swift-stdlib-tool inputs are assembled. Compare the existing _AppleSwiftDylibsInfo inputs with AppleFrameworkImportInfo for imported dynamic frameworks. Done means required Swift dylibs referenced only by an imported framework are included in the scan and covered by the relevant test path.

Written by the indexing model from the issue text.