Integrate deployment binaries with miden-client CLI state

The deployment binaries in `integration/src/bin/` currently set up their own standalone client with hardcoded paths (`../store.sqlite3`, `../keystore`). This means accounts created by the binary are invisible to the CLI and vice versa. A user who creates a wallet via `miden-client new-wallet` cannot use that wallet in the deployment binary without manually wiring up the paths.

The `miden-client-cli` crate already exposes `CliClient` and `CliConfig` as public types, which handle config discovery (local `.miden/` then global `~/.miden/`), store/keystore path resolution, and RPC endpoint configuration. The deployment binary could use `CliClient::new()` instead of the current `setup_client()` to share state with the CLI.

The workflow would look like:

1. User runs `miden-client init` (creates `.miden/` config)
2. User runs `miden-client new-wallet` (creates a wallet in the shared store)
3. User runs the deployment binary, which picks up the existing wallet and uses it to deploy contracts and publish notes
4. User can then use `miden-client` to interact with the deployed contracts (sync, consume notes, check balances)

This removes the disconnect between the CLI and the deployment scripts, and makes the project template feel like a natural extension of the CLI workflow rather than a separate tool with its own state.

The deployment binaries are in `integration/src/bin/`. Examine the current `setup_client()` function and compare it to the `CliClient::new()` and `CliConfig` from the `miden-client-cli` crate. The goal is to replace the standalone client setup in the binaries to use the shared CLI state, ensuring they read from the same config and store paths. Test by running the CLI to create a wallet and then running a deployment binary to see if it picks up the same wallet.

由索引模型根据 Issue 内容生成。