fix(sns-cli): resolve shared local network config in vendored dfx-core

[claude]

What broke

#10640 vendored a subset of dfx-core into rs/sns/dfx-core-vendored, replacing ic-sns-cli's external dfx-core dependency. This broke local-network resolution for downstream consumers, notably dfinity/snsdemo's CI (dfinity/snsdemo#611, dfinity/snsdemo#612), which now fails with:

Error: Failed to build agent for network `local` and identity `None`
...
Caused by:
    0: Failed to fetch root key from network ...
    1: error sending request for url (http://127.0.0.1:8000/api/v2/status)

snsdemo's shared local network is configured (via ~/.config/dfx/networks.json) to bind on 127.0.0.1:8080, not the default 127.0.0.1:8000/127.0.0.1:4943, and snsdemo's project dfx.json does not declare its own networks.local entry.

Why

resolve_local_network() in rs/sns/dfx-core-vendored/src/network.rs decided "project-scoped local network" vs. "shared local network" purely by whether any dfx.json existed above the working directory (via find_project_root()):

let (data_directory, default_address) = match find_project_root() {
    Some(project_root) => (
        project_root.join(".dfx").join("network").join("local"),
        project_local_address(&project_root),
    ),
    None => (
        get_shared_network_data_directory("local")...,
        DEFAULT_SHARED_LOCAL_ADDRESS.to_string(),
    ),
};

This doesn't check whether that dfx.json actually declares its own networks.local entry. A project like snsdemo's, whose dfx.json has no networks key at all, was wrongly routed into the "project-scoped" branch and given the hardcoded 127.0.0.1:8000 default — instead of falling back to the shared network and reading its actually-configured bind address.

This mirrors a gap the PR's own description called out: the shared-network config reading present in the real dfx-core (create_shared_network_descriptor, which reads networks.json's local entry and only falls back to a hardcoded default when that entry is itself absent) was not carried over to the vendored subset. Real dfx-core only takes the project-config branch for a network the project's dfx.json actually declares (create_project_network_descriptor returns None — not an error — when the network isn't present, letting resolution fall through to the shared config).

What this PR changes

In rs/sns/dfx-core-vendored/src/network.rs:

• Replaced find_project_root() (found a dfx.json, unconditionally treated as project-scoped) with find_project_local_network(), which returns the project root and its configured local bind address only when the nearest dfx.json actually has a networks.local entry. Otherwise it returns None, so resolution falls back to the shared network, matching dfx's create_project_network_descriptor semantics.
• Added shared_local_address(), which reads the actual configured bind from the shared ~/.config/dfx/networks.json (via get_user_dfx_config_dir()), falling back to the existing 127.0.0.1:4943 default only when that file doesn't exist or has no local entry. Note the shared networks.json has no top-level networks key (it is the network map), unlike a project's dfx.json.
• Updated resolve_local_network() to use these instead of hardcoding DEFAULT_SHARED_LOCAL_ADDRESS for every dfx-project-adjacent-but-not-declaring case.
• Updated the module doc comment to describe the corrected behavior.
• Added unit tests covering: a project dfx.json with no networks key falling back to the shared network's configured bind (the regression case); a project dfx.json that does declare its own local network taking precedence; and the shared-network default applying when neither config declares local.
• Added a rust_test target to BUILD.bazel for the new tests (serialized via --test-threads=1, since they mutate the process's working directory and the shared-config-directory override).

No change to the external dependency surface — this stays a minimal, in-place bugfix to the vendored subset rather than reintroducing the full dfx-core dependency.

Does not affect canister behavior.