Add GitHub Actions workflow for contract deployment

[rjan90]

Summary

Create a GitHub Actions workflow to deploy FWSS-related contracts, streamlining the upgrade process by eliminating the need to fork the repo, set up local environment variables, and run scripts manually.

Motivation

Currently, deploying contracts requires:

1. Cloning/forking the repository
2. Setting up local environment (ETH_KEYSTORE, PASSWORD, ETH_RPC_URL, etc.)
3. Running deployment scripts manually

This creates friction in the upgrade process. A GitHub Actions workflow would allow authorized team members to deploy directly from the GitHub UI with proper secret management.

Scope

Single workflow supporting deployment of:

Contract	Script	Use Case
FilecoinWarmStorageService	deploy-warm-storage-implementation-only.sh	Most common - every FWSS upgrade
FilecoinWarmStorageServiceStateView	deploy-warm-storage-view.sh	When view logic changes
ServiceProviderRegistry	deploy-registry.sh	Rare - registry upgrades
SessionKeyRegistry	deploy-session-key-registry.sh	Rare - initial deployment only

Proposed Design

Workflow Inputs

• Network: Choice of Calibnet / Mainnet
• Contract: Which contract to deploy
• Dry run: Option to simulate without broadcasting

Secrets/Variables Required

• DEPLOYER_PRIVATE_KEY_CALIBNET - Private key for Calibnet deployments
• DEPLOYER_PRIVATE_KEY_MAINNET - Private key for Mainnet deployments
• ETH_RPC_URL_CALIBNET - RPC endpoint for Calibnet
• ETH_RPC_URL_MAINNET - RPC endpoint for Mainnet

Workflow Outputs

• Deployed contract address(es) in job summary
• Transaction hash
• Blockscout verification status (via existing AUTO_VERIFY)

Note: The workflow will not auto-commit or create PRs for deployments.json. Contract addresses should be verified as working before being added to deployments.json during the announce/upgrade steps.

Acceptance Criteria

• Workflow can deploy each contract type to Calibnet and Mainnet
• Deployed addresses displayed in workflow job summary
• Dry-run mode simulates deployment without broadcasting
• Contract verification runs automatically via existing AUTO_VERIFY
• Documentation in UPGRADE-PROCESS.md updated with workflow usage

Open Questions

1. Keystore vs private key: The scripts currently use ETH_KEYSTORE + PASSWORD. For GHA, should we:
   • Store keystore file content + password as secrets, or
   • Use raw private keys directly (simpler, but requires script modifications to support --private-key flag)