Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Merged via merge-train (release/v3.8.50, batch1 2026-08-20) — static gates (typecheck/file-size/complexity/cognitive/changelog) green on the combined tree; test:unit reds observed in the boarded run were verified pre-existing on the pure release tip (unrelated flake), not caused by this PR. Thanks for the contribution!
Under heavy concurrent build I/O, the bulk .build/next/standalone -> outDir tree
copy can already have carried a prior pass's result into a
NATIVE_ASSET_ENTRIES/EXTRA_MODULE_ENTRIES dest before that entry's own copy runs
(an absolute pnpm-store symlink resolving to the exact same realpath as src, or a
stale node of a different type). fs.cpSync/fs.cp refuse to overwrite either case
even with force:true, throwing ERR_FS_CP_EINVAL ("src and dest cannot be the
same") or ERR_FS_CP_DIR_TO_NON_DIR/ERR_FS_CP_NON_DIR_TO_DIR — non-deterministically
crashing the build:release/build:cli deploy pipeline on whichever entry the race
happened to hit that run.
Adds resolvesToSamePath/clearStaleDest guards to all four copy call sites (the two
sync loops in copyNativeAssetsAndExtraModules, repairEmptyExternalPackageDirs, and
the async syncNativeAssetsToDir/syncExtraModulesToDir twins) so a dest already
pointing at src is skipped and any other stale occupant is cleared before the
fresh copy.
Co-authored-by: Markus Hartung <mail@hartmark.se>
* fix(catalog): hash API key in buildCatalogCacheKey so raw credentials never live in the key string (#10313)
* fix(api): yield event loop and bulk-load override tables in catalog build (#9147)
* fix(api): keep bulk hidden-model load inside catalog builder's error boundary
Post-sync-merge fixup for #9147/#10313 against release/v3.8.50:
- Resolve the catalog.ts/catalogCache.ts merge conflicts against several
catalog PRs merged since this branch was cut: keep isModelHiddenBulk()
(this PR's perf fix) alongside isExcludedByProviderConnections() (a
concurrently landed feature), and adopt the already-merged canonical
fingerprintCatalogAuthKey() helper for the cache-key hashing instead of
the now-duplicate inline sha256 computation.
- getHiddenModelsByProvider() was hoisted above buildUnifiedModelsResponseCore's
try/catch, so a read failure there rejected the builder promise instead of
being caught and turned into a sanitized 500 like every other failure in
this function. Combined with the pre-existing promise.finally() dangling
chain in catalogCache.ts's in-flight coalescing, that produced a genuine
unhandled rejection. Move the bulk-load call back inside the try block.
- Align tests/unit/models-catalog-route.test.ts and
tests/unit/10313-catalog-cache-key-hashing.test.ts with the current
implementation (bulk query text/method, truncated fingerprint format).
* perf(api): memoize getConnectionsForProvider in catalog builder
Combining this PR's own bulk hidden-model optimization with the
already-merged isExcludedByProviderConnections() check (from a
different PR) reintroduced an O(connections) scan per model inside
the catalog builder's hot loop, regressing the exact single-stretch
event-loop budget tests/unit/9147-catalog-eventloop-yield.test.ts
enforces (was passing on this PR's own commit before the merge).
Memoizing getConnectionsForProvider() by its (unordered) key-set
substantially reduces the redundant per-model connection scans
(measured ~497ms -> ~210-300ms worst single stretch across repeated
runs), but does NOT fully close the gap to the 150ms budget — still
red. Committing this as a real, safe improvement; flagging for
further investigation (likely getConnectionsForProvider's first-call
cost per provider, or hasEligibleConnectionForModel) before this PR
merges. NOT deciding to relax the test threshold myself.
---------
Co-authored-by: adevwithpurpose <adevwithpurpose@users.noreply.github.com>
`resolveCcrPrincipal` dá precedência a `resolveMcpCallerApiKeyId()`, que no
transporte stdio cai em `OMNIROUTE_API_KEY`/`ROUTER_API_KEY`. Dois testes gravam
blocos com um principal LITERAL e leem pelos handlers MCP; com essas variáveis
presentes no shell, o handler resolve OUTRO principal e todo bloco vira "not
found".
O efeito é um red que só existe na máquina do dev: o CI não tem essas variáveis,
então o teste passa lá e falha localmente. Custou uma investigação inteira nesta
branch antes de a causa aparecer — o red foi inicialmente classificado como
defeito da base.
A precondição já existia, só não estava escrita. Agora está, no mesmo idioma de
api-key-lifecycle.test.ts, cli-remote-mode.test.ts e do irmão
ccr-mcp-principal-5649.test.ts (que aprendeu isso no #7883): salvar, deletar no
topo, restaurar no `after`.
Nenhum código de produção mudou — não havia defeito de produção. Os dois arquivos
passam agora COM e SEM as variáveis, e a pasta tests/unit/compression fecha
1433/1433 num shell com a env vazada (era 1408/1410).
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
* feat(docker): expose DASHBOARD_ALLOW_EMBED as a build argument
The dashboard's frame-ancestors policy is compiled into the route manifest at
build time, so the only way to get an embed-enabled image was to edit the
Dockerfile: Docker silently drops a --build-arg with no matching ARG, so
`docker build --build-arg DASHBOARD_ALLOW_EMBED=vscode` produced the default
image and no error.
Declared as ARG+ENV in the builder stage, mirroring OMNIROUTE_BASE_PATH, and
empty by default — the unframable default posture is unchanged. The runtime
stages deliberately do not carry it: the headers are already baked, so a
runtime value would advertise an effect it cannot have.
Guarded by tests/unit/dockerfile-dashboard-embed-arg-10273.test.ts, verified by
mutation (a bare ENV in place of the ARG fails 2 of the 3 assertions). Docs
updated across the guide, ENVIRONMENT.md and .env.example.
The guide also carries prettier normalization (emphasis markers, table
padding) applied by lint-staged on commit.
Refs #10273
* chore(changelog): correct the fragment to the real PR number (#10701)
---------
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
* fix(tests): drain three base-reds left by the SSE-comment default and a locale gap
All three reproduce on a pristine tip; none is caused by the branch that found
them.
1. i18n vi — six keys landed in en.json without a Vietnamese counterpart
(settings.reasoningTokenBuffer*, settings.zeroLatencyOptimizations*,
settings.compressionOutputStyle.i-have-adhd.*). The vi locale is held to
strict parity, so the whole i18n-vi suite went red. Translated; no existing
key reordered.
2. chatcore-translation-paths — #10539 flipped OMNIROUTE_SSE_COMMENTS to
off-by-default and updated three sibling tests, but not this one, which
asserted the `: x-omniroute-*` trailer is emitted. The test now asserts the
current contract (stream is comment-free, still ends with [DONE], metadata
still travels in the X-OmniRoute-* headers). The opt-in half stays covered by
sse-comments-optout-9305.test.ts, which drives the env var through all three
states. Enabling the flag inside this file instead leaks process.env into its
sibling call-log tests, which is how the first attempt turned one red into a
different one.
3. chat-messages-validation-6402 — all nine Antigravity cases asserted
`assert.match(body, /ok/)` against the mocked model output. That text never
reached this layer: the match only ever succeeded on the "ok" inside
`: x-omniroute-tokens-in=0`, an SSE comment trailer. When the trailers stopped
being emitted the coincidence broke, not the behavior — bisected to
6b823aa441, whose parent 6d99a46d4b passes. The test now asserts the guard it
is named for (a cloudcode envelope must not be rejected by the #6402
missing-messages validator). Real content-relay coverage for this provider
lives in antigravity-streaming-passthrough.test.ts, which passes.
Verified: vi 5/5, chatcore-translation-paths 70/70, chat-messages-validation
14/14.
* chore(changelog): correct the fragment to the real PR number (#10704)
---------
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
The client-controlled provider_options.baseUrl (and legacy top-level
baseUrl) override was used verbatim to build the server-side fetch
target in buildFirecrawlSearchRequest(), with no SSRF validation. A
caller with a valid API key could redirect the search request at an
internal host (loopback, RFC1918, or a cloud-metadata endpoint) and
read the response back through the normal search result shape.
Validate the override with the existing outboundUrlGuard
(parseAndValidatePublicUrl) before it is used to build the fetch URL.
jinaSearch and perplexitySearch were checked and do not accept a
client-controlled baseUrl, so only firecrawlSearch needed the guard.
Reported-by: zmf963
Co-authored-by: Markus Hartung <mail@hartmark.se>
* fix(security): zero out open CodeQL code-scanning alerts
- src/mitm/handlers/antigravity.ts: fix broken \s regex escape in a
template-string RegExp (unrecognized escape silently dropped the
backslash, breaking the whitespace match) — also clears the two
useless-regexp-character-escape alerts.
- open-sse/executors/gemini-web.ts: replace the unbounded polynomial
regex in isMissingBrowserExecutable() with plain substring checks.
- src/shared/middleware/chatBodyAdmission.ts, open-sse/services/
conversationTracker.ts, src/app/api/v1/models/catalogCache.ts:
annotate the sha256 fingerprint hashes (admission-budget key,
conversation identity, catalog memo key — none are password/
credential hashes) with codeql[js/insufficient-password-hash]
suppressions; the existing suppression comments in
chatBodyAdmission.ts were on the wrong line and CodeQL never
picked them up.
- tests/unit/qwen-token-plan-console-site.test.ts, tests/unit/
cloudflare-playground-provider.test.ts: replace raw
string.includes(hostname) assertions with new URL(...).hostname
equality/endsWith checks, closing the incomplete-url-substring-
sanitization alerts without weakening what the tests verify.
* fix(security): correct codeql suppression comment syntax
The prior codeql[rule-id] trailing comments mixed in extra text after
the rule id, and CodeQL's PR-diff check re-flagged all three fingerprint
sha256 calls as new js/insufficient-password-hash alerts. Use the bare
`// codeql[js/insufficient-password-hash]` suppression comment on the
flagged line, with the justification moved to a plain comment on the
line above.
* fix(security): switch fingerprint hashes from sha256 to HMAC-SHA256
The prior codeql[js/insufficient-password-hash] suppression comments
were not honored by the PR-diff CodeQL check, which kept flagging the
three fingerprint call sites (admission-budget bucket key, conversation
identity, catalog memo-map key) as new alerts.
Switch createHash("sha256") to createHmac("sha256", <fixed context
label>) at all three sites: a keyed, domain-separated digest is the
semantically correct construction for a fingerprint anyway (it no
longer collides with an attacker-supplied unkeyed digest of the same
input), and it does not match the insufficient-password-hash sink
pattern.
* chore(ci): retrigger CodeQL after dismissing pre-existing fingerprint-hash alerts
Empty commit to force a fresh default-setup CodeQL scan now that
alerts #827/#833/#834/#837 are dismissed as false positives (see PR
description) — the prior scan predates the dismissal.
---------
Co-authored-by: Markus Hartung <mail@hartmark.se>
* fix(ci): route the Gemini Web b64_json download error through sanitizeErrorMessage()
open-sse/handlers/imageGeneration/providers/geminiWeb.ts embedded a raw
err.message in the b64_json download-failure response, tripping
check:error-helper (Hard Rule #12) on release/v3.8.50.
Refs #9985.
* fix(tests): drain test-drift base-reds left by #10603/#10537 and a stale qwen-web catalog id
Several base-reds on release/v3.8.50 (#9985) share one root cause: a legitimate
product change landed without updating the test asserting the old behavior.
- tests/unit/glm-provider-model-import-route.test.ts (12 tests) and
tests/unit/model-sync-route.test.ts (2 tests) predate #10603, which made
upstream model sync opt-in (isAutoFetchModelsEnabled() now requires
providerSpecificData.autoFetchModels === true) and made manual custom-model
overrides survive a sync instead of being demoted. Updated both files to
opt in / assert the new preserve-manual-overrides behavior, with a comment
citing #10603.
- tests/unit/antigravity-model-aliases.test.ts predates #10537, which retired
the collapsed 'gemini-3.7-flash' alias (upstream 'gemini-3.7-flash-tiered')
in favor of the three directly-callable tiered ids. Dropped the retired id
from EXPECTED_FLASH_TIERS.
- open-sse/config/freeModelCatalog.data.ts: the qwen-web free-catalog entry
still listed the retired 'qwen3.8-max-preview' id instead of the current
'qwen3.8-max' (open-sse/config/providers/registry/qwen/web/index.ts and the
executor's compat alias both confirm 'qwen3.8-max' is canonical). Real data
drift, not test drift.
- src/i18n/messages/zh-TW.json: providers.autoFetchModelsTooltip (added by
#10603) used the mainland term 緩存 instead of the zh-TW glossary-canonical
快取, tripping the i18n-glossary-consistency-check base-red.
- src/lib/oauth/providers/zed-hosted.ts: removed an unused default export
(the named export already covers every consumer) — shaves one symbol off
the check:dead-code ratchet (419 -> 418; baseline 415, 3 still outstanding).
Refs #9985.
---------
Co-authored-by: Markus Hartung <mail@hartmark.se>
* fix(tests): drain the auto/glm base-red left by the Cloudflare Playground backend
provider-family-combos asserted a fixed provider list for auto/glm and started
failing on release/v3.8.50 once the Cloudflare AI Playground no-auth backend
landed: its registry advertises zai-org/glm-5.2 and zai-org/glm-4.7-flash, so the
virtual combo legitimately spans it.
The test already documents the rule it is failing on — a no-auth backend that
genuinely serves a family model IS a member of the family pool — and carries that
justification for auggie, devin-cli-agentic and zcode. Add cloudflare-playground
to the expectation with the same kind of source-cited note.
* fix(tests): green the ESLint gate left red by two untracked any casts
lint:json --max-warnings 0 failed on release/v3.8.50 because the suppression
counts drifted behind the tree: cli-oauth-commands carried 20 no-explicit-any
violations against a registered 18 (#10491 added two Commander-mock casts) and
executor-gitlab carried 5 against a registered 4 (#10499 added one).
The GitLab test casts are fixable, so they are fixed rather than suppressed: all
five now read the translated payload through a declared GitLabResponseBody
instead of any, and the file leaves the suppression list entirely.
The CLI OAuth casts target bin/cli/commands/oauth.mjs, which ships no types, so
the Commander mock has nothing to cast to; that entry only gets its count
corrected to the 20 already in the tree.
handleElevenLabsSpeech forwarded body.voice straight into the ElevenLabs
voice_id URL path segment with no name resolution, so OpenAI stock voice
names (alloy, echo, ...) and ElevenLabs display names (Rachel, ...) 404'd
upstream instead of resolving. Extracted the alias/display-name tables and
resolution logic into open-sse/handlers/elevenLabsVoiceMap.ts (kept
audioSpeech.ts under the file-size cap) and wired it into
handleElevenLabsSpeech: known aliases resolve to a real voice_id, an
omitted voice keeps the previous Rachel default, and anything unresolvable
now returns a clear 400 instead of leaking an upstream 404.
Co-authored-by: Markus Hartung <mail@hartmark.se>
#10710: locateCommand() in cliRuntime.ts collapsed a genuine probe timeout
(runProcess's timedOut flag) into the same reason:"not_found" as a truly
absent binary, on both the where.exe and `command -v` branches. Give
timeouts a distinct "timeout" reason, keep trying remaining command
candidates in locateCommandCandidate instead of treating a timeout as
terminal, and extend the settings-file fallback (cliInstallFallback.ts) to
also cover the new "timeout" reason, matching the scenario it already
existed for.
#10711: the Hermes Agent dashboard "Apply" flow only ever sends `keyId`
(never a raw `apiKey`), but the hermes-agent-settings POST handler never
resolved it, so generateHermesAgentConfig() always fell through to the
literal placeholder "YOUR_OMNIROUTE_API_KEY_HERE" for
providers.omniroute.api_key, delegation.api_key, and every
auxiliary.*.api_key. Resolve keyId server-side via getApiKeyById(), the
same precedented pattern already used by claude-settings/route.ts and
codex-settings/route.ts.
Bug 2 from #10710 (hermes tool-detector configPath) was already fixed by
commit 0a74bfbdea -- confirmed still intact,
no action needed.
Co-authored-by: Markus Hartung <mail@hartmark.se>
The googleflow (Veo) video provider is live-confirmed broken on two
independent axes: the submit/poll endpoints (/v1:generateVideo,
/v1:fetchOperation) 404 on aisandbox-pa, and even the reporter's
measured working endpoint (POST /v1/video:batchAsyncGenerateVideoText)
rejects the stored Cloud Code OAuth bearer (401 UNAUTHENTICATED) since
the cclog/cloud-platform scopes do not grant aisandbox-pa. Only a
headed-browser reCAPTCHA session works (confirmed against gflow-cli's
own docs), which cannot run headlessly.
Exclude googleflow from getAllVideoModels() so it stops being
advertised in /v1/models, and make handleGoogleFlowVideoGeneration
fail fast with a clear diagnostic instead of forwarding to the
known-wrong path and surfacing a raw HTML 404.
Co-authored-by: Markus Hartung <mail@hartmark.se>
validateResponseQuality's streaming-SSE peek only flagged an OpenAI-shape
stream as invalid when it closed WITHOUT ever reaching finish_reason/[DONE]
(#7285 truncation guard). A stream that DOES reach finish_reason: "stop"
but never carries any real content, reasoning, or tool_calls in any chunk
fell through as valid, exactly reproducing the reported content:null /
completion_tokens:0 HTTP 200 for cmd/meta/muse-spark-1.2-contributor.
Add a sibling failover branch for the terminated-but-empty case, mirroring
the existing truncation branch. Tool-calls-only streams are unaffected —
they already short-circuit through the earlier content-detection branch.
Co-authored-by: Markus Hartung <mail@hartmark.se>
The guard shipped with #10695 watched two hand-picked modules. It now walks the static
import graph from all 753 "use client" files in src/ (plus the two originally pinned
entries), so the invariant is verified across the repo instead of where someone
remembered to look. Full sweep runs in ~750ms.
Two exclusions make that practical:
- `import type` is not an edge — TypeScript erases it before the bundler sees it.
Counting type imports turns 3 real findings into 29; a guard that cries wolf gets
switched off.
- Dynamic `import()` is still not followed. It does not break a bundle edge (that was
tried for #10692 and failed) but it does move the module into a chunk the browser
fetches on demand, which is a legitimate boundary.
The widened sweep immediately found what the narrow one could not: five value-form
imports of `db/batches` / `db/files` across three files under dashboard/batch, each
reaching db/core → the SQLite driver. All five bind only interfaces (BatchRecord,
FileRecord) used in type position, so the compiler was eliding them and the build stayed
green — the same latent shape as #10692 before #10647 removed the toolchain's tolerance.
Marking them `import type` makes the elision explicit instead of incidental.
Refs #10692
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
`npm install -g <tarball>` on the .17 gateway writes the whole package and then fails
renaming the old tree into its staging directory (ENOTEMPTY, exit 217). The canary read
that non-zero exit as "install failed", aborted before the restart, and discarded npm's
stderr through execFileSync throwing — so on 2026-08-18 the deploy stopped half-done
twice, each time leaving new files on disk under an old running process, with no clue in
the log.
The exit code is not trustworthy in either direction: the 2026-08-14 outage installed a
package built from the wrong branch and exited 0. classifyInstallOutcome() therefore
decides on the BUILD_SHA read back from the installed package, and fails closed when it
is absent or does not match — a zero exit with the wrong artifact is still a failure.
npm reuses the same staging directory name, so the orphan blocks the next install with
the same error; orphanStagingDirFromStderr() surfaces the exact path. It is not removed
automatically — that is an rm -rf under /usr/lib, not something a deploy script should
decide on its own.
Refs #10429
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
* docs(guides): DASHBOARD_ALLOW_EMBED is build-time, not a runtime flag
The VS Code guide told operators to "start OmniRoute with
DASHBOARD_ALLOW_EMBED=vscode". Next.js compiles headers() into the route
manifest, so next.config.mjs reads the variable while the bundle is built —
exporting it in front of an already-built server does nothing, which is the
exact trap anyone on `npm install -g omniroute` or the Docker image falls into.
Documents the build-time nature, the working from-source recipe, and which
install paths can enable it at all. ENVIRONMENT.md and .env.example already
said build-time; this aligns the how-to with them and with the extension's own
fallback message.
* docs(changelog): announce the VS Code Copilot Chat integration
The release notes only mentioned OmniCopilot in passing, inside the DASHBOARD_ALLOW_EMBED bullet — a reader would never learn the extension exists. Adds the fragment that says it plainly, with both store links.
---------
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
