The workspace builds libsql without its `tls` feature, so a
`backend.libsql` config panicked at startup with "The `tls` feature is
disabled, you must provide your own http connector", for every remote
URL including plain `http://`.

pnpr now gives libsql its own connector. It is built on the workspace's
rustls 0.23 with the aws-lc-rs provider, and it verifies servers against
the platform trust store through rustls-platform-verifier. Enabling
libsql's `tls` feature instead would add hyper-rustls 0.25 and a second
rustls release. The lockfile gains no new crates.

- The trust store is loaded only for URLs libsql dials over HTTPS, so an
  `http://` database works on a host without CA certificates. The
  `http://` check is case-insensitive.
- A connector built for HTTPS refuses plain-HTTP URIs, so a `base_url`
  in a Hrana response cannot move the auth token out of TLS.
- An `authToken` with a non-loopback `http://` url fails at startup,
  the HTTPS-or-loopback rule pnpr-client applies to its credentials. With a
  token, the connector also refuses each later plain-HTTP request to a
  non-loopback host.

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

…6837)

The Clippy and Doc tasks declare `outputs: []`, so `pnpm pipeline` caches
their results, keyed on every file in the repository plus `RUSTFLAGS` (and
`RUSTDOCFLAGS` for Doc). Their jobs no longer pass `--no-cache`.

A new `remote-cache` composite action points the pipeline at Vercel Remote
Cache. It runs only in the merge queue and on pushes to main, which also
sign and publish their results, so the Vercel token never reaches pull
request code. The push to main tests the tree the merge queue already
tested, so its Clippy and Doc rows restore the results instead of
recompiling. The action does nothing until the token, team, and public key
are configured.

The credentials live in the remote-cache environment, which only main and
the merge queue branches can use, so a workflow on a pushed branch cannot
read the signing key.

Dylint keeps `--no-cache`: its run on main saves the build cache pull
requests restore, and a cache hit would leave that cache stale.

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

First step of the tool: protocol RFC (pnpm/rfcs PR 37). `tool:` is
accepted wherever a user writes a `runtime:` specifier: the node, bun,
deno and yarn resolvers, `pnpm add`, `pnpm update`, `pnx`, the
engines.runtime fold on manifest write, global shims, deploy, catalog
mode, and locked-version reuse. The lockfile freshness check treats
`tool:<spec>` and `runtime:<spec>` as equal, so either spelling in
package.json satisfies a lockfile written with the other.

`yarn@tool:<range>` maps to its Yarn line (npm `yarn`,
`@yarnpkg/cli-dist`, or the zpm release archives) the same way
`yarn@<range>` does, in `pnx` and in the install selector that `pnpm add`
and `pnpm add -g` use.

pnpm still writes `runtime:` in every specifier it saves, in lockfile
keys, and in resolved versions. engines.runtime and devEngines.runtime
store no protocol and read back as `runtime:`, so writing `tool:` into
the lockfile's importer specifiers would make a lockfile that earlier
pnpm versions reject on a frozen install. Switching to `tool:` needs the
lockfileVersion major bump the RFC schedules for the next major.

The spelling lives in a new leaf crate, pnpm-tool-protocol, so the
manifest, lockfile, resolver, and CLI crates share one definition.

Let trusted CI jobs manage npm tags without a stored npm token.

Reuse the publish command's OIDC login for dist-tag add, rm, and ls.
Get a temporary token for the selected package and registry. Keep configured
credentials as the fallback when OIDC is unavailable or rejected.

Keep tokens in memory and skip provenance checks for tag changes.

In both CLIs, send an injected NPM_ID_TOKEN only when its aud claim matches
the selected registry, so a repository-selected registry cannot receive the
CI identity token.
Add tests, documentation, and changesets.

Related to npm/cli#10038.

---------

Co-authored-by: Zoltan Kochan <z@kochan.io>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…#16843)

A rebuild with skipIfHasSideEffectsCache still ran the build of a package
whose side-effects row is empty: a build that changed nothing inside the
package, such as ssh2's install script when its optional native binding
cannot compile. Since #14744 the store's read path drops empty
rows from the overlays, so the is_built gate never sees them, and such a
package ran its script on every rebuild. An embedder that installs without
a modules directory and then rebuilds the pending packages re-ran these
scripts each time.

pnpm v11's rebuild checks only that the store index has a row for the
cache key (`pkgFilesIndex.sideEffects.has(key)`), empty or not. This
matches it: the build phase now also gets the raw rows, and a rebuild
with skip_if_has_side_effects_cache treats an empty row for the key as
built, with nothing to materialize, unless the package directory carries
the build marker of a global virtual store slot that was never built. The
dependency graph is built for the gate when such rows exist even if no
overlay does. The overlays and the rows travel together as
CachedSideEffects. An install keeps
running these builds, since their effect may lie outside the package
directory (#14717).

Release the pending pacquet intents as a patch, since 12.12.0 has not
been marked latest yet. The dist-tag OIDC and tool: protocol intents
move from minor to patch. The rebuild skip entry is dropped from the CLI
page because only the `@pnpm/napi` rebuild() can enable
skipIfHasSideEffectsCache.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>