Integrate `Source`/`Resource`/`Subresource` framework with `resourceIndexer`/`ResourceVersions`/`ListResources` framework

A big tension between the `Source`/`Resource`/`Subresource` framework and the `resourceIndexer`/`ResourceVersions`/`ListResources` framework is that the former is built around dynamically-constructed URLs (relying on, e.g., conventions and external queries) while the latter is built around statically-constructed and stored URLs. The point they interact—`Subresource.url()` calls `Resource.versionInfo()` which uses `Resource.versionDescriptor`—is awkward and ill-fitting because of this tension. These two very different ways of doing things collide and subvert each other. For example, a `Resource` without a `versionDescriptor` represents the “latest” or “live” version of the resource, while one with a `versionDescriptor` abdicates behaviour entirely by jumping out of the `Source`/`Resource`/`Subresource` framework and into `ResourceVersions` and the resource index framework. It would be clarifying to intentionally do things just one way. Either: 1. Move past version handling into `Source`/`Resource`/`Subresource` framework. `ResourceVersions`/`ListResources` go away and become part of `Source`/`Resource` instead as new methods and logic. Possibly an additional `ResourceVersion` (singular!) class in the hierarchy as a way to separate concerns about a resource as a whole (i.e. with many versions) from its specific versions. This doesn’t preclude statically-constructing indexes of our resources; it means that indexes are *built* and *used as part of* the dynamic construction approach. For example, `resourceIndexer` would *make (partial) use* of `Source`/`Resource`/`Subresource` classes. In #1249, I did a very little bit of this with the indexer using `NextcladeSource`. or 2. Move all version handling, including “latest” (i.e. no version descriptor), into `resourceIndexer`/`ResourceVersions`/`ListResources` framework. `Source`/`Resource`/`Subresource` stop dynamically constructing URLs and *always* consult the resource index. The resource index in turn needs to become more dynamic and be able to be updated in a more timely manner. This effectively makes the resource index much more like a live database we query as the source of truth. Pragmatically, it's likely easiest to start with (1) so that we don't have to improve the indexer's lag time right away. Doing (1) first does not preclude moving to (2) further down the road (and probably makes it easier).