qmd fork drift: upgrade path from pinned feat/remote-llm-provider branch

[jaylfc]

TinyAgentOS installs qmd from the jaylfc fork on branch `feat/remote-llm-provider`, currently pinned to commit `b6c1019e`. The upstream PR (tobi/qmd#511) is under review but not merged. Until it lands we're exposed to fork drift in both directions:

Risks:

• Upstream refactors the hot path (`llm.ts`, `qmd.ts`, `store.ts`) and our fork becomes harder to rebase
• Upstream ships a bug fix we want but it touches code the fork has rewritten
• A user re-runs `install-server.sh` months from now and gets a surprise version bump because HEAD of the branch moved

What needs to happen:

• Pin install-server.sh to a specific commit SHA, not a branch name (currently pulls `github:jaylfc/qmd#feat/remote-llm-provider` which resolves to HEAD at install time)
• Document the rebase-onto-upstream process in `docs/design/framework-agnostic-runtime.md` so updates are reproducible
• CI smoke test: nightly rebase of our fork onto `tobi/qmd/main` and run the qmd serve test suite; open a conflict issue if it breaks
• When upstream feat(browser): isolated proxy origin + service worker (SPAs work in the Browser app) #511 merges, collapse the fork back into a thin set of additional PRs (sequential-load scheduler, rerank fixes) against upstream main instead of maintaining a full fork

User impact today: Low — installs work because the pin is stable. The risk materialises when a user upgrades and the HEAD of the branch has advanced.

Spec: This issue tracks the operational cleanup, not a protocol change. No new design doc required.