chore(deps): plugin-workers-core and plugins/triggers import plugin-streams-core without declaring it

[rickylabs]

Summary

Two workspace members import @netscript/plugin-streams-core without declaring it in their own
deno.json imports. Both resolve today through workspace resolution, so nothing is broken locally —
the question is whether the published artifacts carry a complete dependency declaration.

Evidence

• packages/plugin-workers-core/deno.json does not list @netscript/plugin-streams-core, while
  packages/plugin-workers-core/src/streams/producer.ts:1 and
  packages/plugin-workers-core/src/streams/schema.ts:1-2 import it.
• plugins/triggers/deno.json does not list it either, while
  plugins/triggers/streams/producer.ts:7, plugins/triggers/streams/factory.ts:12, and
  plugins/triggers/streams/schema.ts:12 import it.

By contrast plugins/workers/deno.json does declare it, and the workers manifest declares
.withDependencies({ streams: streamsPlugin }) (plugins/workers/src/public/mod.ts:61) — so the
declaration pattern exists and these two are inconsistent with it.

What is not yet known

Whether deno publish actually rejects this was not verified. It was raised by the #1398
research pass and confirmed by the #1398 PLAN-EVAL, both of which recorded it as unverified rather
than asserting a failure. Do not assume it is broken; the first step is to run
deno task publish:dry-run and find out. If publishing succeeds, this is a consistency and
readability issue rather than a release-integrity one, and should be closed or downgraded on that
evidence.

Acceptance criteria

• deno task publish:dry-run evidence recorded for both packages, stating whether the missing
  declaration is rejected, warned about, or silently accepted
• Either both deno.json files declare @netscript/plugin-streams-core, or the reason a
  workspace-resolved import needs no declaration is documented where the next person will look
• If publishing is affected, a check fails on an undeclared cross-package import rather than
  surfacing at publish time

Why it was not fixed in place

Raised inside the 0.0.6 runtime lane while implementing #1398 and deliberately fenced out of that
PR's scope: #1398 is a runtime-behaviour fix with live E2E acceptance, and absorbing an unrelated
dependency-declaration change would have widened a p1 slice that was already carrying a public
behaviour change. Recorded as R3 in
.llm/runs/release-0.0.6-features--orchestration/plan.md and carried here rather than dropped.

Refs #1398.