The accelerating bitrot of `osx-64` and falling download numbers

Dropping support for _anything_ related to the size of the pool of potential users is always a contentious topic in conda-forge. We've taken forever to move to [cos7](https://github.com/conda-forge/conda-forge.github.io/issues/1436), move to [macOS 10.13](https://github.com/conda-forge/conda-forge.github.io/issues/1844) (much less [11.0](https://github.com/conda-forge/conda-forge.github.io/issues/2467)), and we haven't come to a conclusion on [ppc support](https://github.com/conda-forge/conda-forge.github.io/issues/2510) either.

To a degree, this is healthy - we shouldn't drop support at the first opportunity - but on the other hand, we need to be pragmatic enough to pull the plug on stuff if there are either no more users, or we cannot provide a baseline level of packaging quality (bugfree-ness, security posture).

I don't/didn't think that `osx-64` would be up for debate in the near future, but on the other hand, a lot of signs are accumulating. Anaconda [dropped](https://www.anaconda.com/blog/intel-mac-package-support-deprecation) Intel Macs this summer, many other big packages (e.g. upstream pytorch) have long done so as well (and we're struggling quite a bit with [v2.9](https://github.com/conda-forge/pytorch-cpu-feedstock/pull/446) due to this). There are many more stories of upstream osx-64 support bitrotting quickly, but those were all around non-central packages that we can mostly work around (like we do for the whole google-sphere of packages like [abseil, grpc, protobuf](https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/4075#issuecomment-3040639363), etc.).

However, what caught my eye was that `cryptography` will drop support for osx-64 in their next release: https://github.com/pyca/cryptography/issues/13520. Since `osx-64` is [still](https://doc.rust-lang.org/nightly/rustc/platform-support.html) a tier-2 platform in Rust (the guts of cryptography, ever-increasingly), I expect us to be able to keep things going for a while longer, but this really is a clarion call IMO. If - for whatever reason - we lose the ability to publish security-critical library updates on a given platform, that's the absolute latest point where we have to declare it dead and gone.

Other relevant data points:
* The last pre-M1 hardware was sold into 2020 AFAICT
* `osx-64` is still supported until MacOS 26 (Tahoe), which is the [last one](https://www.pcmag.com/news/apple-confirms-end-of-support-for-intel-macs-after-macos-tahoe) to support (some) Intel macs
* MacOS 26 will be EOL upstream in Sept. 2028, if the [recent patterns](https://endoflife.date/macos) on these dates hold
* Microsoft is deprecating the osx-64 CI agents (while still far behind in delivering [osx-arm64 agents](https://github.com/conda-forge/conda-forge.github.io/issues/1781)); once that happens, we'd have to switch to cross-compiling `osx-64` from `osx-arm64`. In theory this should be exactly what we've been doing for years the other way around (i.e. cross-compiling `osx-arm64` from `osx-64`), but at our scale, I wouldn't be surprised if issues arise from having to do that switch.

Download numbers (as taken through the proxy of `cryptograpy`, which, as any proxy, is far from perfect) have also been falling off a cliff in the last year (these are only `osx-*` downloads from PyPI, courtesy of the cryptography maintainers)

Conda(-forge)'s own data is tainted by the downloads from our own CI, see: https://github.com/anaconda/anaconda-package-data/issues/64

Overall, I think we _could_ probably squeeze another 2, 3, 4 years out of `osx-64` to the degree that stuff builds without issue (assuming the cross-compilation switch works ~smoothly, and key packages stay compilable with minimal patching), but I wanted to document the situation as I was looking into it a bit this week. And perhaps people have other opinions or additional data points about the whole thing.