CLI: add a command to print the currently-deployed contract's wasm hash

Start by reading the existing stellar contract upload command and the RPC getLedgerEntries path mentioned in the issue. Add the proposed stellar contract wasm-hash --id <CONTRACT_ID> command to read the contract's executable instance entry and print its hash. Done means the output can be compared with a local sha256sum and supports audit or CI checks.

When upgrading or auditing a Soroban contract, there is no CLI command to see
the wasm hash the contract is currently running.

stellar contract upload prints the sha256 of a wasm you upload, but there is
no counterpart that reads the hash of the executable currently installed at a
contract address.

1. What problem does your feature solve?
   After deploying or upgrading a Soroban contract there is no simple way to
   answer: "what wasm is this contract actually running right now?"

stellar contract upload prints the sha256 of a wasm you upload, but there is
no command that reads the hash of the executable currently installed at a
deployed contract address. As a result developers cannot:

• confirm the deployed code matches the artifact they built (compare with
  sha256sum of the local .wasm)
• detect that a contract they depend on was upgraded to a hash they never
  approved

2. What would you like to see?
   A command that returns the currently-installed wasm hash for a contract, e.g.:

   stellar contract wasm-hash --id <CONTRACT_ID>

reading the executable entry from the contract's instance data.

With it you can:

• compare the live hash against sha256sum of your local build to prove the
  deployed bytecode matches your source before releasing funds
• keep an upgrade audit trail by combining the uploaded hash, the
  executable_update event, and the live hash
• wire the check into CI so a deploy or a rogue upgrade can't go unnoticed

3. What alternatives are there?

• Fetch the contract's executable instance entry via the RPC
  (getLedgerEntries) and decode the hash manually — possible, but every
  developer ends up re-implementing it.
• Third-party verification tools read the same entry; having it in the
  official CLI makes the check trivial and CI-friendly.
• Leave the CLI as-is — the gap stays: no convenient way to verify what is
  actually deployed.