Possible feature: Obsidian community catalog submission

[sadigaxund]

Split out of #13 (steps 1 through 3 shipped: the markii-obsidian release mirror, embedded worker/wasm assets in main.js, and BRAT installs verified in a real vault).

The remaining step, only if demand shows up: a PR to obsidianmd/obsidian-releases to list the plugin in the community catalog. The manifest is already conformant (id markii, isDesktopOnly true, minAppVersion set), and the release channel already satisfies the tag == manifest version rule. Still needed at submission time: a versions.json in the mirror repo, and a review pass against Obsidian's plugin guidelines.

Not scheduled; pick up when people ask for a catalog install.

[sadigaxund]

Merged in from #26 (closed 2026-08-31): the BRAT install gap and the compiler command.

A BRAT install carries only the three core files, so a pack shipped as source cannot compile until the esbuild-wasm folder sits next to main.js. Two variants were analyzed for a "Markii: Install pack compiler" command; which one ships depends on whether a catalog submission is pursued, so the decision lives here.

Variant A, no download (recommended first): the command opens the release page pinned to the installed plugin version and names the exact folder to drop next to main.js. Human in the loop, no policy exposure, about an hour of work. The existing cannot-build-packs notice names this command instead of naming the zip install.

Variant B, verified download: explicit command with a confirmation that states source, version, and size (roughly 14 MB from the Markii 0.5.x release). Fetch over Obsidian's requestUrl from the markii-obsidian release asset matching the installed version, unzip with fflate, write only inside the plugin's own folder, verify a build-time embedded hash or byte length and fail closed with a plain notice. Diagnostics log the URL and the verified hash. Never auto-triggered, never reachable from note content. The mirror workflow would gain an esbuild-wasm.zip asset per release.

Why the order: Obsidian's developer policies frown on plugins downloading executable code at runtime, and the wasm runtime qualifies. Over BRAT this is unreviewed and fine; for a catalog submission variant B could be a rejection reason. Ship A now if BRAT users get stuck, upgrade to B only if A still leaves people stranded and the catalog is not pursued.

Not for VS Code: the extension bundles the compiler in dist.

[sadigaxund]

Implemented as variant A in b91a5fe: the plugin never downloads anything itself. From the next Obsidian release on, the workflow attaches esbuild-wasm.zip as a release asset and the notes tell BRAT users to extract it next to main.js to enable compiling packs from source.

[sadigaxund]

Reopened: only the CI half landed. Still open here: the optional Install pack compiler command that points at the pinned release asset, and the community catalog submission itself, which stays unscheduled until demand shows up.