verify(sdk): confirm the published @netscript/sdk JSR landing page shows the canonical query dialect

[rickylabs]

Summary

#1377's final acceptance row is observational — it can only be checked against a published
artifact, so no pull request can close it:

[post-merge] The published JSR landing page for @netscript/sdk shows the canonical dialect.

The content that satisfies it merged in PR #1541 (packages/sdk/README.md now leads with
createQueryFactories rather than the demoted createServiceQueryUtils), and
jsr-package-settings.json:6 sets readmeSource: "readme", so that file is the JSR landing
page. But whether jsr.io renders it correctly is only observable after @netscript/sdk publishes.

This issue carries that verification forward so #1377 can close on work that is actually done,
rather than being closed with an unverified row and no tracker.

Why it exists as a separate issue

milestone-run.md § Honesty rules: "Observational criteria cannot be closed by a PR — route them to
a verification issue in the next milestone (#1090 pattern) at the moment you notice it, not at cut
time."

The docs lane recorded this obligation when it opened, and the gate PR (#1586) carries
Closes #1377. Without this issue, that merge would close #1377 with a row nobody can honestly tick
and nothing tracking it — the stranded-scope failure the close-gate rules exist to prevent.

Verification steps

After the next @netscript/sdk publish:

1. Open https://jsr.io/@netscript/sdk and confirm the landing page renders the README from
   packages/sdk/README.md (per readmeSource: "readme").
2. Confirm the page leads with createQueryFactories as the golden-path query API.
3. Confirm createServiceQueryUtils appears, if at all, only as the narrower non-golden-path helper
   — matching docs/site/reference/sdk/index.md:111, which distinguishes its queryOptions({ input })
   shape from the golden-path queryOptions(input) and notes it has no server KV tier.
4. Confirm no lib/api-clients.ts reference survives on the rendered page.

Acceptance criteria

• The published @netscript/sdk JSR landing page leads with createQueryFactories.
• The rendered page contains no lib/api-clients.ts reference.
• The verified release version and the observation date are recorded on this issue.
• docs(reference): publish-readiness paths still disagree with the plugin-core reference IA, and public README drift remains #1377's [post-merge] row is ticked, referencing this issue.

Boundaries

• The source work is complete and merged (docs(reference): reference IA completeness, README truth, and CLI verb coverage #1541). This issue is observation only — if the
  rendered page is wrong, the defect is in publishing or rendering, not in the README, and that gets
  its own issue.
• fix(mcp): agent-docs prose corpus is a stale pre-#1373 snapshot — 60 api-clients references still ship to agents, and no CI check can see it #1531 owns the stale MCP agent-docs corpus. Different surface, different defect.

Provenance

Filed by the 0.0.6 documentation-lane orchestrator, prompted by the fallback IMPL-EVAL of PR #1586,
which found the routing commitment recorded in that slice's plan.md had been dropped in its
context-pack.md and never executed — the row was correctly left unticked, but no verification issue
existed to carry it.

[rickylabs]

Verified and closed at the 0.0.7 Step 0 publication checkpoint. JSR registry metadata reports latest: 0.0.6; the live @netscript/sdk landing page identifies 0.0.6 and renders the canonical SDK positioning, including typed service clients, cache-aware query factories, the one-contract-map/three-surfaces model, and the explicit “Two query dialects — pick one per data layer” section. Evidence: https://jsr.io/@netscript/sdk, https://jsr.io/@netscript/sdk/meta.json. This issue is observational and requires no code PR.