release 0.0.9907

[piscisaureus]

Bumps the version in deno.json to 0.0.9907. Includes:

• chore: update @deno/framework-detect to 0.3.3 #144 @deno/framework-detect 0.3.3: deno.json deploy.buildTimeout
  in seconds or with an s/m/h suffix

[avocet-bot]

Review: #145 — "release 0.0.9907"

Reviewed head SHA: 037f011e45274a67acd8f94817823e63780b379f
Author: piscisaureus (Bert Belder) · Base: main · Head: release-0.0.9907

What this PR does (background for a reader new to the repo)

deploy-cli is the command-line tool / library published to JSR as the package
@deno/deploy. Its package manifest is deno.json, which carries both the
package's own published version and its dependency import map. Releases in this
repo are cut by a dedicated, minimal PR that only increments the version field;
the actual feature/dependency work lands in earlier, separately-reviewed PRs that
merge to main first.

This PR is exactly that kind of release cut. The entire diff is a single line:

-    "version": "0.0.9906",
+    "version": "0.0.9907",

The PR body notes the release "includes #144" — the bump of
@deno/framework-detect to 0.3.3 (which adds support for deploy.buildTimeout
expressed in seconds or with an s/m/h suffix). That dependency change is
already on main (merged via #144, which I reviewed earlier), so it does not
appear in this PR's diff; this PR only stamps the new version number onto the
release that will carry it.

Verification performed

1. Diff is exactly the self-version bump. Only the version field of the
   @deno/deploy package changes, incrementing monotonically 9906 → 9907,
   consistent with the prior release cadence (#141 → 9905, #143 → 9906).

2. The @deno/framework-detect 0.3.3 claim is consistent at head.
   deno.json at this SHA pins jsr:@deno/framework-detect@^0.3.3, and
   deno.lock resolves it to 0.3.3. Nothing about the dependency is left
   dangling by this release.

3. deno.lock does not need (and does not get) an update. A package's own
   version field is never recorded in its own lockfile, so a self-version bump
   correctly requires no deno.lock change. None is missing.

4. The ^ vs ~ appearance in the lock is NOT drift. Every caret-pinned
   0.x import in deno.json (framework-detect, sandbox, jsonc-morph, @std/tar,
   dax) appears in the ~ form in deno.lock. For 0.x versions ^0.3.3 and
   ~0.3.3 denote the identical range (>=0.3.3 <0.4.0); Deno normalizes them in
   the lockfile. This is uniform across all deps and is expected behavior.

5. Publish risk is low. The JSR publish dry-run checks are green at head,
   confirming 0.0.9907 is a valid, previously-unpublished, publishable version.
   (Per prior experience on this repo, main's deno CI job can be
   pre-existing-red on two cli_contract tests; a pure version-string change
   cannot affect those, so any red there would be pre-existing and not
   attributable to this PR — attribute by comparing pass/fail counts to base, not
   the raw red.)

Findings

No blocking issues. No non-blocking findings. This is a clean, consistent
release-version bump with no correctness, regression, security, concurrency, or
edge-case concerns, and no missing lockfile update.

Recommendation

Approve.

---

Review skill evidence

• Invoked the pr-review-toolkit:code-reviewer subagent (via the Task/Agent
  tool) as the primary review pass. It independently fetched the diff, deno.json,
  and deno.lock at head and confirmed: the diff is the single version line, the
  lockfile needs no update, framework-detect 0.3.3 is consistent, the ^/~
  form is a false alarm, and publish dry-runs are green.
• Reviewer corroborated the subagent's findings against head-SHA blob reads
  (deno.json, deno.lock) and the PR metadata.