fix(fresh-ui): regenerate the private lock for the Fresh plugin-vite workspace dependency

[rickylabs]

Release-blocking evidence

After PR #1558 added @fresh/plugin-vite to packages/fresh/deno.json, the package-private lock at packages/fresh-ui/deno.lock was not regenerated.

The dedicated Fresh UI package quality workflow now fails on current main during its frozen package type-check:

Fresh UI private lock is stale. Review the dependency diff, then run deno task --cwd packages/fresh-ui lock:update and commit packages/fresh-ui/deno.lock.

Concrete reproducer: PR #1570, workflow run 31603374728, job 94136055380.

Measured root cause

In an isolated detached worktree at exact current main db1d79c68f7861a43902313f5d7a68274b0ef12a, with Deno 2.9.5:

deno task --cwd packages/fresh-ui lock:update
exit 0

packages/fresh-ui/deno.lock | 1 +
1 file changed, 1 insertion(+)

The sole generated entry is the new dependency already declared by the packages/fresh workspace member:

       "packages/fresh": {
         "dependencies": [
           "jsr:@fresh/core@^2.3.3",
+          "jsr:@fresh/plugin-vite@^1.1.2",
           "jsr:@netscript/ai@0.0.5",

This is distinct from #1571 / PR #1572, which repairs the root deno.lock. The private Fresh UI lock is an independent frozen gate and must not be hidden inside an already evaluated immutable head.

Acceptance

• packages/fresh-ui/deno.lock is regenerated by the package's canonical lock:update task using Deno 2.9.5, never hand-edited
• The diff is exactly the one generated workspace dependency entry above, with no unrelated movement
• deno task --cwd packages/fresh-ui check passes frozen
• A second lock:update plus frozen check leaves packages/fresh-ui/deno.lock byte-identical
• The Fresh UI package quality workflow is green on the repair PR and on the dependent quality-gate PR fix(quality): make quality gate coverage informative #1570

Workflow

This is a small deterministic generated-lock correction. PLAN-EVAL is N/A and IMPL-EVAL may use the documented skip label. It must land before PR #1570 and before the final 0.0.6 stable cut.

[rickylabs]

[PHASE: REVIEW] — acceptance proof, all five boxes

Repair merged as 50739a7ae (PR #1581, Refs #1580 — deliberately non-closing, because box 5 could only be satisfied after that merge). Each box below is ticked against already-recorded evidence, verified rather than asserted.

#	Box	Proof
1	Regenerated by the canonical lock:update with Deno 2.9.5, never hand-edited	Slice ran deno task lock:update from packages/fresh-ui; the result equals the deterministic output the orchestrator measured independently at db1d79c68 before dispatch
2	Diff is exactly the one generated workspace dependency entry, no unrelated movement	git diff --numstat origin/main...HEAD → 1 0 packages/fresh-ui/deno.lock; the single added line is + "jsr:@fresh/plugin-vite@^1.1.2",. Merged head verified after the branch moved (889936dc3 → 7b8488211, which only removed a brief file)
3	deno task --cwd packages/fresh-ui check passes frozen	failedBatches: 0 (was 2 of 2 before the repair). Confirmed again on merged main and independently by the coordinator: 150 files / 2 batches / 0 failures
4	A second lock:update + frozen check leaves the lock byte-identical	sha256 across a full second check + test pass: 77de591c8c2d8ac4e7c46901f24e87a95b044fd7bde416933b7610b3f958c7c8 both times. The coordinator measured the same hash on merged main from a separate checkout
5	Fresh UI package quality green on the repair PR and dependent #1570	Repair PR #1581: fresh-ui-quality pass. Dependent #1570 at head 807d29003963834211aaf4b17b3fe26bd65bbf94: SUCCESS — https://github.com/rickylabs/netscript/actions/runs/31605497993/job/94143265702 (verified via the API: conclusion: success, head_sha matches #1570's live head)

Scope note

Box 5 asks specifically for the Fresh UI package quality workflow to be green on #1570 — that is now proven at the exact head. It does not require #1570's unrelated broad lanes to pass or #1570 to merge; internals retains full ownership of #1570's CI and merge, and this closure makes no claim about them.

Root cause, owned

This issue existed because I mis-classified a deterministic lock closure as incidental build-toolchain churn during #1459 and enforced a hand-reduced delta. That single decision produced two stale locks — the root one (#1571, still open pending Canary.3) and this private one. A hand-reduced lock delta does not fail at the point of the edit; it fails later, elsewhere, in someone else's red — here, as a fresh-ui-quality failure on an unrelated lane's PR.

Closing as completed.