chore(governance): populate empty deno.lock with minimal valid v4 lockfile

`deno.lock` has been an empty (0-byte) file since commit 3b03087
("chore: track (empty) deno.lock for M5 sweep", 2026-05-21). Deno 2.x
treats empty lockfiles as a parse error:

    error: Failed reading lockfile at '/.../deno.lock'
    Caused by: Lockfile was empty

The estate governance check
(`governance / Language / package anti-pattern policy` in
governance-reusable.yml) runs
`deno run --allow-read .standards-checkout/scripts/check-ts-allowlist.ts`
which fails on lockfile parse before reaching the actual `.ts` walk.

Fix: write the minimal valid Deno-2 lockfile JSON:

    { "version": "4", "remote": {} }

This preserves the "track lockfile" intent of 3b03087 (the file stays
committed and visible to estate-wide sweeps) while letting Deno 2.x
parse it. When real remote imports are added, `deno cache --lock` will
populate the `remote` object on its own.

Effect: `governance / Language / package anti-pattern policy` returns
green; the check-ts-allowlist.ts walker actually runs.

Refs: #92 (the broader baseline failures, this PR addresses the
language anti-pattern slice only).

Author: hyperpolymath