distribute/transfer: move results accumulator off $GITHUB_ENV to avoid unbounded growth

Background

Follow-up to #69 (PR #70).

The distribute and transfer sub-actions accumulate their results across steps by newline-appending JSON into $GITHUB_ENV variables (FLY_DISTRIBUTE_RESULTS, FLY_TRANSFER_RESULTS), which the root action's post step reads to render the job summary.

PR #70 bounded the per-entry size by persisting only the fields the job summary renders (slim projections, dropping files[]/download_count for distribute and message for transfer). That removes the realistic failure mode.

Remaining concern

The mitigation does not change the underlying mechanism: the variables are still appended across every step, so total size grows with the number of distribute/transfer steps. With slim entries this is tiny in practice, but it's still technically unbounded against the Linux single-env-var limit (MAX_ARG_STRLEN, 128 KB) that caused #69.

Proposal

Stop using $GITHUB_ENV as the accumulator. Write the accumulated results to a temp file at a known path (e.g. under $RUNNER_TEMP) that the post step reads, which is not subject to MAX_ARG_STRLEN. $GITHUB_STATE is not a drop-in because state is scoped per action instance and the reader is a different action (the root post step), so a shared temp file is the cleaner approach.

This is the truly root-cause fix; the projection in #70 is a sufficient mitigation in the meantime.

Inspect the distribute and transfer sub-actions and the root action's post step to trace how results are appended to and read from $GITHUB_ENV. Confirm the shared temporary-file path and update the accumulator and reader so results no longer use an environment variable; done means accumulation remains available to the post step without unbounded environment-variable growth.