updated generate_v3 workflow to automatically release and bump cli/terraform provider

[habfast]

Description

Shortcut story: sc-178260

From the story:

We should improve the automation around releasing new versions of our public toolings. Here's the current situation:

• public-api is our public server gateway and exposes an openapi schema
• egoscale (current project) is our go SDK, and is auto-generated based on that openapi schema. On a daily basis, the schema is pulled, and if there are any changes then a PR is created. At this point, we need to manually review and merge the PR, and possibly create a new release by updating the changelog and creating a git tag.
• cli is our command line utility, and makes use of egoscale. We need to wait for a new release of egoscale, then update it, and then manually build the feature that we want.
• story is almost identical with terraform-provider-exoscale.

This is very tedious and wastes a lot of time. I want to automate it all using github actions:

I propose to change the egoscale daily job so that it:

1. pulls the latest version of the public-api schema
2. generates the new version of the egoscale client
3. pulls the cli and terraform code bases, updates the egoscale dependency, tries to build them and run the tests.
4. IF everything works smoothly, then update the CHANGELOG.md file, commit the changes directly to master, and trigger a new release.
5. once the new release is done, update the egoscale dependency in both cli and terraform-provider-exoscale, and commit to master

The goals are that:

• I can go to the cli repo in the morning, and the current version of the SDK matches the current version of the openapi schema.
• if any team breaks the compatibility of their openapi schema, then it becomes their burden as they've broken the automation.

Notes for the reviewer

• CHANGELOG format is hardcoded. The script assumes the existing RST-style header (Changelog\n=========) and a static "regenerate from new API spec" entry. Any format change to CHANGELOG.md may break this.
• I have gone with the assumption that this will run in the middle of the night and that we magically won't run into concurrency issues
• If there are breaking changes in the OpenAPI schema, we won't be releasing, however I have not implemented any notification system yet...
• We need to configure a PAT. @brutasse / @arnaudgeiser ideally this would be as a github app that has read/write access to the three repos and read access to the repos metadata. I'll replace the secrets.CROSS_REPO_PAT in the PR once I have the name of the app.

Use of AI: A first version of the new workflow was written by Qwen 3.6 27b. I then manually reviewed and iterated with Claude Opus until I got it where I wanted.

Checklist

(For exoscale contributors)

• Changelog updated (under Unreleased block)

[wdullaer]

Running CLI and Terraform tests as regression tests in the automated run is a fine idea.

However, I would not commit to the terraform and cli repos from this repo.

I would trigger a workflow in the CLI and terraform repos that pull the latest release, test and commit.
This gives less permission to this repo, but also gives us the opportunity to rerun the builds in CLI and terraform in case something goes wrong.

See https://github.com/exoscale/cli/blame/master/.github/workflows/release.yml#L9-L14 for some inspiration.

Lastly: it might be worth moving the build and tests into earthly, since that allows us to run them easily locally on your machine.

The things that remain in gha are the creation of releases and triggering of remote workflows.

As it stands, I don't want to have to debug this workflow.