More clearly describe how Obsidian determines which plugin release to download

Right now, the process for how Obsidian determines which plugin release to download isn't clearly defined, and is spread out across multiple pages.

• Submit your plugin states that you must have a manifest.json in the root folder of your repository.
• Submission requirements for plugins also states that you must have a manifest.json in the root folder of your repository, and before creating a release, update the version in the manifest.json following Semantic Versioning.
• Manifest describes the schema for manifest.json, version is "The version, using Semantic Versioning in the format x.y.z." and minAppVersion is "The minimum required Obsidian version."
• Versions describes how Obsidian will fallback to using versions.json in the root folder of your repository if the Obsidian app version is lower than the minAppVersion in the manifest. versions.json contains a JSON object, where the key is the plugin version, and the value is the corresponding minAppVersion.

It would be nice if there was one page where the full flow of how Obsidian determines which plugin to release to download is defined, step by step. Something like this:

1. Obsidian checks version in manifest.json in root folder of repository on default branch. If version >= version in locally downloaded manifest.json then plugin is up to date, stop.
2. If Obsidian app version >= minAppVersion in manifest.json in root folder of repository, then download release matching version in manifest.json in root folder of repository.
3. If there is not a versions.json in the root folder of repository, stop, plugin fails to update/install.
4. Find the highest version (key) in versions.json that has a min app version (value) <= Obsidian app version. Install matching release. Otherwise plugin fails to install.

It may also be nice to show a mermaid diagram, as it can be hard to describe the process, something like this:

flowchart TD;
gteqVersion{"Downloaded Manifest.version >= Manifest.version on HEAD"}
noUpdateNeeded["No update needed"]
obsidianVersionGteqMinAppVersion{"Obsidian app version >= Manifest.minAppVersion on HEAD"}
downloadRelease["Download release matching Manifest.version on HEAD"]
versionsExists{"versions.json exists on HEAD"}
fail["Plugin fails to install/update"]
obsidianVersionGteqVersionsMinAppVersion{"Obsidian app version >= minAppVersion in versions.json"}
downloadVersionsRelease["Download release matching highest version in versions.json with a minAppVersion >= Obsidian app version"]

gteqVersion -- Yes --> noUpdateNeeded
gteqVersion -- No --> obsidianVersionGteqMinAppVersion
obsidianVersionGteqMinAppVersion -- Yes --> downloadRelease
obsidianVersionGteqMinAppVersion -- No --> versionsExists
versionsExists -- Yes --> obsidianVersionGteqVersionsMinAppVersion
versionsExists -- No --> fail
obsidianVersionGteqVersionsMinAppVersion -- Yes --> downloadVersionsRelease
obsidianVersionGteqVersionsMinAppVersion -- No --> fail

I think the wording needs more work, but it would help to alleviate confusion. I'm happy to put more work into this and submit a PR.

This is inspired by a conversation on the OMG Discord, starting around here, with some debate starting here.

Start by comparing the Submit your plugin, Submission requirements for plugins, Manifest, and Versions pages to identify the authoritative release-selection flow. Confirm the disputed wording with maintainers, then consolidate the steps and, if appropriate, add a Mermaid diagram so the completed documentation clearly explains update, fallback, and failure outcomes.