docs: clarify the privacy boundary of remote transaction proving

## Context

The builder docs present remote proving primarily as a way to offload CPU-intensive proof generation:

- `docs/builder/tools/clients/web-client/setup.md`
- `docs/builder/tools/clients/web-client/transactions.md`
- `docs/builder/tools/network.md`
- `docs/builder/faq.md`

That is accurate, but these pages do not currently state the trust/privacy boundary created by selecting a remote prover.

In `0xMiden/rust-sdk@next`, `RemoteTransactionProver` is documented as sending witness data to a remote gRPC server, and the request payload is the serialized `TransactionInputs`:

- [`crates/rust-client/src/remote_prover/tx_prover.rs#L17-L18`](https://github.com/0xMiden/rust-sdk/blob/next/crates/rust-client/src/remote_prover/tx_prover.rs#L17-L18)
- [`crates/rust-client/src/remote_prover/tx_prover.rs#L90-L90`](https://github.com/0xMiden/rust-sdk/blob/next/crates/rust-client/src/remote_prover/tx_prover.rs#L90)
- [`crates/rust-client/src/remote_prover/tx_prover.rs#L116-L121`](https://github.com/0xMiden/rust-sdk/blob/next/crates/rust-client/src/remote_prover/tx_prover.rs#L116-L121)

`TransactionInputs` may contain the partial account, input notes, transaction arguments, advice inputs, foreign account code, and foreign storage-slot names:

- [`crates/miden-protocol/src/transaction/inputs/mod.rs#L52-L63`](https://github.com/0xMiden/protocol/blob/next/crates/miden-protocol/src/transaction/inputs/mod.rs#L52-L63)

This does not mean those inputs are exposed to the Miden network. It means the configured proving endpoint must receive the execution inputs needed to generate the proof. Local proving keeps that boundary on the client; delegated proving moves it to the selected prover.

## Existing related work

- Wallet issue [#478](https://github.com/0xMiden/wallet/issues/478) and merged PR [#609](https://github.com/0xMiden/wallet/pull/609) already describe local proving as the more private option while keeping keys on-device. This issue is about aligning the builder-facing documentation with that distinction and documenting the code-confirmed request boundary.
- Docs issue [#195](https://github.com/0xMiden/docs/issues/195) tracks endpoint references, not the privacy/trust semantics of using an endpoint.
- Node PR [#969](https://github.com/0xMiden/node/pull/969) explores TEE attestation for confidential delegated proving, but it is still open and normal remote-prover configuration should not imply an attested TEE.

## Scope questions

Before drafting a docs patch, could maintainers confirm the intended framing?

1. Should the docs explicitly say that a remote prover receives the serialized transaction witness/inputs required for proving, while signing keys remain on-device?
2. Is it accurate to recommend local proving for the strongest client-side privacy, and to describe a remote prover as a service the user or application must trust with the proving request unless an additional confidential-compute guarantee is established?
3. Would a short callout in the two web-client pages, plus a concise note in the delegated-proving FAQ, be the preferred scope? I would avoid duplicating the full explanation on the network endpoint inventory page.

If this framing is correct, I am happy to prepare a small documentation-only change. It would not change prover behavior or make claims about a particular hosted endpoint beyond what the client and protocol types establish.

Review the linked documentation files (`docs/builder/tools/clients/web-client/setup.md`, `transactions.md`, `network.md`, `faq.md`) and the Rust SDK code (`crates/rust-client/src/remote_prover/tx_prover.rs`, `crates/miden-protocol/src/transaction/inputs/mod.rs`) to understand the data sent to a remote prover. The task is to add a clear explanation of the privacy boundary, distinguishing between local and remote proving. The change is documentation-only, so focus on editing the markdown files to include the agreed-upon framing from the maintainers' feedback.

Scritto dal modello di indicizzazione a partire dal testo della issue.