Summary

When a project is vendored ("vendor": true), deno run --no-remote fails to
resolve jsr: (and npm:) package manifests even though they are present in
the vendor/ directory. It tries to fetch the manifest remotely and aborts:

error: JSR package manifest for '@std/cli' failed to load. A remote specifier
was requested: "https://jsr.io/@std/cli/meta.json", but --no-remote is specified.

This is inconsistent with how --no-remote handles vendored https://
(deno.land/x) specifiers, which are remapped to local files and work offline.
The error message is also misleading: it claims a remote specifier "was
requested" when the manifest is sitting on disk in vendor/.

Split out of #26488 (the rest of that issue was a usage question, answered by
--cached-only).

Version

deno 2.8.1 (also reproduces on main, a205a85a53)

Reproduction

mkdir vbug && cd vbug
export DENO_DIR="$PWD/denodir"   # isolated cache we control

cat > deno.json <<'JSON'
{ "vendor": true }
JSON

cat > server.ts <<'TS'
import { parseArgs } from "jsr:@std/cli/parse-args";
console.log("ok", parseArgs(Deno.args));
TS

# 1. vendor (online)
deno cache server.ts
ls vendor/jsr.io/@std/cli/meta.json    # vendored manifest is present

# 2. delete the global cache so vendor/ is the ONLY local source
rm -rf "$DENO_DIR"

# 3. run fully offline
DENO_OFFLINE=1 deno run                server.ts   # ✅ ok
DENO_OFFLINE=1 deno run --cached-only  server.ts   # ✅ ok
DENO_OFFLINE=1 deno run --no-remote    server.ts   # ❌ error (below)

Expected

With the global cache wiped and only vendor/ present, the no-flag and
--cached-only runs both succeed offline by reading
vendor/jsr.io/@std/cli/meta.json and parse_args.ts from disk. --no-remote
should resolve the JSR/npm manifest from the vendor directory the same way, and
run successfully offline.

Actual

--no-remote ignores the vendored manifest and attempts a remote fetch of
https://jsr.io/@std/cli/meta.json, then errors out, under the exact same
conditions where the no-flag run succeeded using the vendored file.

Notes

• Once a project is vendored, plain deno run is already offline-capable, so
  --no-remote is not required for offline use; --cached-only also works.
  This issue is specifically about --no-remote not honoring vendored
  jsr:/npm: manifests.
• At minimum, the error message should not claim a remote fetch when a vendored
  manifest exists, and should point users to --cached-only.