[rule based toolchain] rule based API needed to contribute to runtime search paths

Rule-based toolchains can use `cc_args` to express precise link behavior, including -L paths, -l libraries, link-mode selection, and ordered linker state such as --as-needed or --start-group.

For example:
```starlark
cc_args(
name = "glibc_dynamic_link_args",
actions = ["@rules_cc//cc/toolchains/actions:link_actions"],
args = [
"-L{glibc_library_search_path}",
"-Wl,--push-state",
"-Wl,--as-needed",
"-lc",
"-lpthread",
"-ldl",
"-Wl,--pop-state",
],
data = [
"//runtimes/glibc:glibc_library_search_directory",
],
format = {
"glibc_library_search_path": "//runtimes/glibc:glibc_library_search_directory",
},
)
```

The missing part is runtime handling. Dynamic libraries selected this way can be available to the link action, but they do not become runfiles and do not contribute to runtime_library_search_directories.

cc_toolchain.dynamic_runtime_lib provides runtime handling for toolchain dynamic libraries, but we can't use that when we need to control ordered linker flags for the same runtime libraries.

It would be useful for rule-based toolchain configuration to express toolchain dynamic runtime libraries so binaries and tests get matching runfiles and runtime search paths.

This is the last missing piece for https://github.com/hermeticbuild/hermetic-llvm to be able to provide 100% hermetic runtimes compiled from source both statically and dynamically.

Start by tracing the rule-based `cc_args` flow and the existing `cc_toolchain.dynamic_runtime_lib` handling described in the issue. Determine how the new API should connect selected dynamic runtime libraries to runfiles and `runtime_library_search_directories`, then verify that binaries and tests receive matching runtime paths.

Written by the indexing model from the issue text.