Migrate ServiceProviderRegistry upgrade tooling to `announceUpgradePlan`

## Context

PR #547 adds `announceUpgradePlan(address,uint96)` to `ServiceProviderRegistry`, but the existing operator helper, `service_contracts/tools/service-provider-registry-announce-upgrade.sh`, still exclusively generates the deprecated `announcePlannedUpgrade((address,uint96))` call with an absolute `AFTER_EPOCH`.

The currently deployed registry implementations predate the new selector, so the first upgrade that introduces it must still be announced through the legacy interface. After that upgrade, registry announcements should use a relative delay so Safe signing time does not consume the requested notice window.

## Scope

Bring the ServiceProviderRegistry operator flow in line with the FWSS dual-mode transition introduced in #547.

## Acceptance criteria

- Add a delay-based mode that calls `announceUpgradePlan(address,uint96)` and accepts `UPGRADE_DELAY_EPOCHS`.
- Make delay mode the normal/default path once the deployed registry supports the selector.
- Preserve an explicit `ANNOUNCEMENT_MODE=legacy` bootstrap path using `AFTER_EPOCH` for:
- the first upgrade from an implementation that predates `announceUpgradePlan`;
- rollback to such an implementation while that rollback remains supported.
- Reject ambiguous configurations that set both delay and absolute-epoch inputs.
- Preflight-simulate the selected call from the proxy owner before producing calldata, so an unsupported selector, invalid implementation, or overflowing delay is caught before a Safe proposal is created.
- After execution, read back `nextUpgrade()`, verify the implementation and effective `afterEpoch`, and record the observed epoch as the source of truth.
- Update the tooling README/runbook to explain the per-network transition from legacy to delay mode.
- Document the cleanup condition: remove legacy mode after both deployed registries support the new selector and rollback to the older implementation is retired.
- Add or update tests/checks for both modes and their validation paths.

## Sequencing note

Selector availability is determined by the implementation currently behind each network's registry proxy. Calibnet and Mainnet may therefore require different modes during the transition.

Start with service_contracts/tools/service-provider-registry-announce-upgrade.sh and the existing tooling README/runbook, then compare the registry interface and transition described in PR #547. Trace how the script selects and simulates announcements, validates inputs, and reads nextUpgrade(). Done means both legacy and delay modes, their validation checks, post-execution verification, and the per-network cleanup guidance are covered by tests or checks and documentation.

Written by the indexing model from the issue text.