feat: add aleph deployment workflows

[NiKrause]

Summary

This PR adds an Aleph-based deployment path for universal-connectivity.

It introduces:

• a reusable uc-go-peer workflow that builds and publishes the RootFS and can optionally deploy and verify a VM
• a shared Aleph VM deploy action used as the deployment primitive
• a UC-owned Aleph contract and relay probe policy under go-peer/aleph/
• js-peer publishing through Aleph so the browser client and RootFS manifest can be published as part of the same flow

Why

This is for operating UC as a deployed relay service on Aleph Cloud rather than only as a local or generic peer runtime.

The intended flow is:

1. build a uc-go-peer RootFS image
2. publish the image to IPFS and Aleph
3. optionally deploy an Aleph VM instance from that RootFS
4. publish js-peer with the RootFS manifest
5. when a VM is deployed, verify the relay and republish js-peer with the final bootstrap data
6. retain only the latest successful deployments

Required Repository Configuration

Before using these workflows end to end, the repository needs the following repository secrets and variables.

Secrets

• ALEPH_PRIVATE_KEY
  Hex-encoded Ethereum private key for the wallet that signs Aleph messages.
  This wallet is used to publish and pin the js-peer site and the RootFS image on Aleph/IPFS, and also to create Aleph VM instances when deploy_vm=true.
  In practice, holding ALEPH on that wallet is enough to use the current hosting model for these artifacts. For example, publishing a js-peer site plus a RootFS image of roughly < 700 MB does not currently require spending under the current Aleph business model, but the wallet still needs to be the account that owns and manages those hosted resources.

• VM_SSH_PUBLIC_KEY
  SSH public key that should be authorized inside the deployed Aleph VM.
  This is used when deploy_vm=true so the resulting instance can be accessed over SSH for inspection, debugging, or recovery.

Variables

• ALEPH_DOMAIN
  Optional custom domain for the published js-peer site.
  When this is set and the workflow runs on main, the workflow can attach or relink that domain to the latest published site.
  This requires the DNS setup expected by Aleph custom-domain hosting:
  https://aleph-console.testnet.network/computing/custom_domain/setup/#overview

• ALEPH_RETENTION_DAYS
  Optional retention hint for Aleph web hosting uploads.
  This controls how long preview or published site artifacts should be retained by the hosting layer when that workflow path supports retention configuration.

• ALEPH_VM_CRN_HASH
  Optional default CRN hash for VM deployment.
  If set, the deploy workflow will prefer that specific Aleph CRN instead of selecting one automatically.

Without these values, parts of the workflow may still run, but publish, deploy, SSH access, and custom-domain behavior will not work fully.

Scope

This PR covers the Aleph workflow and operations layer:

• .github/actions/aleph-vm-deploy/action.yml
• .github/workflows/build-aleph-go-peer-rootfs.yml
• .github/workflows/uc-go-peer-rootfs-reusable.yml
• .github/workflows/js-peer.yml
• go-peer/aleph/uc-go-peer.json
• go-peer/aleph/relay-probe-policy.json
• go-peer/aleph/README.md