> Not every project records email addresses in the source code.
You have missed the point entirely.
The email Git workflow is based around—you guessed it—git. Git, being designed entirely around email-based workflows, stores the email authors and committers of every commit (they often differ), and furthermore, often also marks the reviewers. This is fully automatic.
If you are looking for email addresses, you either A) do not have the prerequisites for doing the work in the first place, or B) do not understand git.
Any Git tree that has not been intentionally butchered will contain the email address of every single maintainer and contributor to ever have contributed to the project, and that is always the only thing you need when doing email workflows.
(Linux stores more than that, for convenient official subsystem maintainer lookup—but focusing on the extra processes that a project that in 2019 alone had over 74k commits from 4k authors with over 5 million lines of code changes needs is a little silly when we're talking about comparatively tiny projects where git info is fine.)
> How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!?
You are derailing significantly. If you have not yet figured out how to obtain a git tree, then you have clearly gotten ahead of yourself with most of your arguing. How can you be discussing how to create issues if you don't even know how to get the software in the first place to discover issues with? How do you even know of the software if you had not already found a place which could contain the starting point for your process?
Nothing with relation to workflows and VCS has any important before you manage to get ahold of the software in the first place, whether that is on a website, forge, IPFS, USB dongle smuggled by a packer over a border, or whatever you'd like.
The starting point, however, is nothing more than that. It serves no purpose once "recruitment" is complete, as you work on your machine-local repo from there. You may occasionally sync with other individuals trees, in what can be considered peer-to-peer transactions, but even that is mostly optional, and it can be done with any individual. You do not need full consensus in the tree.
(The tarballs you refer to are not for development. They're only releases for end-users, which cannot be used to make patches from.)
> I can only guess that you're using mental model of Linux kernel development.
The development model are used for many other projects, including a handful of mine.
If you think that there are no adversaries out to kill Linux, you'd be sorely mistaken, but it's moot as it has no single points of failure. Everyone works on their own trees, and send around patches, occasionally syncing in various directions.
---
The fact that you have now assigned several disconnected components as focal points underlines the fact that there are, in fact, none. I have also come to the conclusion that you are not very familiar with neither git itself nor the email workflows it was developed to sustain.
Granted, there will always be central individuals, in the form of the maintainers of the subtree you are contributing to (note: there can be any number of maintainers and subtrees for a given project). This is not due to infrastructure, but due to code changes losing meaning if arbitrary patches are applied in arbitrary order. But, there is no single point of failure and no single point of gathering.
But, even then, they are not focal points. The various maintainers act as focal area of a particular subtree, but they are organic and redundant, and loss of one is is easily routed around as any holder of a tree can accept patches and act as a maintainer. And loss of one implies loss of an individual, not loss of a random hosting service.