Post-hook for tweaking `build-local-artifacts` binaries?

Over in [air](https://github.com/posit-dev/air) we'd like to codesign our Windows binaries generated by cargo-dist. Ideally this would involve some kind of adjustment made to the Windows binary itself _after_ cargo-dist has created it, but _before_ any kind of SHA has been created for it (but I'd also be willing to recreate the SHA value myself as well, as a Sufficiently Motivated User).

There doesn't really seem to be a great way to do this from what I can tell.

I'm going to list out a few things I considered, but none of them really feel like the obvious way to do this, and I'd appreciate any advice.

## `build-local-artifacts = true` with a `local-artifacts-jobs`

The current state of [this pr](https://github.com/posit-dev/air/pull/461/changes) involves having

```
build-local-artifacts = true
local-artifacts-jobs = ["./codesign-windows-binaries"]
```

where `codesign-windows-binaries.yml` _needs_ the `build-local-artifacts` job to run first.

`codesign-windows-binaries.yml` fetches the windows specific github artifacts from the `build-local-artifacts` job, codesigns them, regenerates SHAs, and overwrites the artifacts.

But because `local-artifacts-job` wasn't really intended for this, the `custom-codesign-windows-binaries` job that dist creates for us doesn't set `needs: build-local-artifacts`, so this doesn't create the right DAG in the action.

## `build-local-artifacts = false` with a `local-artifacts-jobs` that copies the `build-local-artifacts` job

I had a thought that maybe I could turn `build-local-artifacts` off, and then have a `local-artifacts-job` that did exactly what `build-local-artifacts` did, i.e. i'd copy and paste this over into a new workflow file

https://github.com/posit-dev/air/blob/4cbd36d552e27d8930cff1602d56bfd9ce4c1ed1/.github/workflows/release.yml#L92-L167

I tried that [here](https://github.com/posit-dev/air/pull/461/changes/f174a6d719abd48787c421ca2e556f3dd17fd632#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R97-R99), but it requires `dist build ${{ needs.plan.outputs.tag-flag }}`, and the `local-artifacts-jobs` job doesn't get to access that. It only gets:

```
with:
plan: ${{ needs.plan.outputs.val }}
```

Even if this worked, it would not have been my preferred solution because I could easily get out of sync with dist.

## `build-local-artifacts = true` with a fully custom `local-artifacts-jobs`

The nuclear option is to just take control of building _all_ the binaries and making all the SHAs and uploading them all, for all targets we want to support.

I don't really want to do that if I don't have to. It would stink to have to do that just to shove in some code signing for windows.

## Post-GitHub Release artifact modification?

In theory maybe I could let `release.yml` finish as-is, and actually churn out a github release. Then I could go in and modify that github release in place, replacing the windows binary and sha with codesigned versions. But that feels very gross 😢. To me, a github release should feel pretty immutable!

Start by tracing cargo-dist's build-local-artifacts job and the generated custom-codesign-windows-binaries job, focusing on how local-artifacts-jobs receives the plan and how dependencies are emitted. Compare this with .github/workflows/release.yml lines 92-167 and the referenced dist build command; done means a post-build Windows hook can run before SHA generation without duplicating the release workflow.

Written by the indexing model from the issue text.