Modular tooling approach for service_contracts operational scripts

## Context

We have a growing set of operational scripts under `service_contracts/tools` for deployment, upgrades, and contract operations. They are currently Bash-heavy, which has been effective for getting workflows in place quickly, but it is starting to make reuse, composition, and testing harder.

## Problem

As the number of scripts grows, we are accumulating:
- duplicated logic around chain selection, deployment address loading, and Safe interactions
- inconsistent operator UX across scripts
- limited structure for shared modules and tests
- more Bash to maintain over time

## Goal

Evaluate whether we should keep building on the current Bash approach, or move some or all of this tooling to a more modular implementation approach.

## Things to explore

- whether there is enough common logic now to justify a shared toolchain
- whether a different language/runtime would improve modularity and code sharing
- whether we should standardize a common CLI/operator interface across scripts
- whether we should add shell tooling now even if we keep Bash for the near term

## Near-term improvements to consider even if we keep Bash

- add `shfmt`
- add `shellcheck`
- document conventions for script inputs/outputs
- identify common helpers that should be consolidated

## Outcome

A recommendation on:
1. stay with Bash + add better tooling, or
2. migrate future operational tooling to a more structured toolchain

Start by inventorying the scripts under service_contracts/tools and tracing duplicated chain selection, deployment address loading, and Safe interaction logic. Review the near-term shfmt, shellcheck, and shared-helper options, then document a recommendation between improving Bash and adopting a structured toolchain, including the proposed operator interface and testing approach.

Written by the indexing model from the issue text.