Add deployment registry selector

[timothyF95]

Summary

Adds an optional deployment-registry field to user-workflow settings that lets workflow commands resolve registry configuration dynamically from context.yaml instead of using hardcoded environments.yaml defaults. When omitted, behaviour is unchanged (backward compatible). Off-chain registries are gated in production and rejected by on-chain-only commands (deploy, pause, activate, delete) with a clear error until off-chain routing is implemented.

Changes:

• New DeploymentRegistry field on UserWorkflowSettings, read via Viper
• ResolveRegistry helper resolves registry by ID from tenant context, branching on type (on-chain / off-chain), with fallback to EnvironmentSet defaults
• ResolvedRegistry wired into runtime.Context; deploy, pause, activate, delete read from it instead of EnvironmentSet directly
• RequireOnChainRegistry guard rejects off-chain registries early with an actionable error message

Example workflow.yaml

staging-settings:
  user-workflow:
    workflow-name: "my-workflow-staging"
    deployment-registry: "onchain:ethereum-testnet-sepolia"           <--- new (optional)
  workflow-artifacts:
    workflow-path: "."
    config-path: "./config.staging.json"
    secrets-path: ""

Precedence hierarchy

deployment-registry set?
├── YES → context.yaml registry entry (env vars ignored)
└── NO  → CRE_CLI_WORKFLOW_REGISTRY_* env var
          └── not set → embedded environments.yaml default

[timothyF95]

This was moved to avoid an import cycle

[j-nowak]

Maybe we could extract the type as cosnts/enums?

[j-nowak]

Does it make sense to resolve a registry without an address?

[j-nowak]

Have you considered how the code would look like if we had 2 different types representing onchain/offchain regsitry? I'm not the biggest fan, where we have a bag of fields unrelated for a given object type.