Change minutes hosting method.

[davidlehn]

The minutes repo is very large due to many older meeting audio recordings. This is causing issues when trying to commit and deploy updates. The pages system can time out due to the time it takes to process the large amount of data. Alternate approaches to hosting the audio files should be considered so a text based data site could be deployed without these issues.

[davidlehn]

See #13.

[BigBlueHat]

One option is storing the audio files with git LFS (which may incur a fee...depending on quotas for this org). It is now possible to use GitHub Actions to publish to GitHub Pages and actions/checkout has LFS support and those can be used in tandem as outlined at https://github.com/orgs/community/discussions/50337

However, we'd want to be careful about when the Action is triggered, so we don't burn through any LFS quotas accidently (i.e. moving all the audio files around for changes to code/logs/HTML, etc.).

Consequently, being that careful may be more trouble than it's worth...

[BigBlueHat]

Another alternative is putting the audio files in a different host (S3, Cloudflare R2, etc.). We don't record/upload these anymore, but even if we did, we could automate those uploads.

The steps to do this would look like...

1. moving the files to a storage/object provider
2. changing the references in any past published minutes / metadata

The most annoying thing would be that we'd get an entirely separate permissions space and audio management would have to happen away from the rest of the code and content...which I find suboptimal...

More to consider.