fix(database): bound recovery checkpoint path

Summary:
Reuse the bounded canonical checkpoint basename for selected-database recovery so recovery cannot reintroduce the Windows SQLite path amplification removed from automatic startup.

Refs:
- Change: spec/changes/active/windows-canonical-authority-second-launch
- Change: spec/changes/active/database-resource-lifecycle-hardening

Verification:
- Desktop canonical storage recovery test: 6/6 passed
- Desktop typecheck: passed
- Focused Desktop ESLint: passed
- Spec governance and traceability: passed for 15 active changes
- Affected-file Prettier and git diff --check: passed
- Full release harness and real Windows packaged two-launch gate: pending final isolated candidate

Author: legeling

apps/desktop/src/main/services/canonical-storage-recovery.ts

@@ -88,7 +88,7 @@ function recoverSelectedDatabase(
     checkpointPath: path.join(
       options.activeRoot,
       "cache",
-      `.canonical-recovery-checkpoint-${process.pid}-${crypto.randomUUID()}`,
+      `.canonical-checkpoint-${crypto.randomUUID()}`,
     ),
     deviceId: deriveLocalResourceDeviceId(options.activeRoot),
     mcpLibrary,

apps/desktop/tests/unit/main/canonical-storage-recovery.test.ts

@@ -2,6 +2,7 @@
  * @vitest-environment node
  */
 import { beforeEach, describe, expect, it, vi } from "vitest";
+import path from "node:path";
 import type { ExtractedMcpSecret } from "@prompthub/core";
 
 import type { McpResourceSecretEncryption } from "../../../src/main/services/mcp-resource-secret-store";
@@ -93,7 +94,7 @@ describe("canonical storage recovery orchestration", () => {
     });
   });
 
-  it("closes SQLite and rebuilds canonical storage with device-bound secrets", async () => {
+  it("closes SQLite and rebuilds through a bounded checkpoint with device-bound secrets", async () => {
     const onSuccess = vi.fn();
     const onFailure = vi.fn();
     const scheduleRelaunch = vi.fn();
@@ -152,15 +153,21 @@ describe("canonical storage recovery orchestration", () => {
         activeRoot: "/root",
         sourceDatabasePath: "/root/data/prompthub.db",
         deviceId: "device-test",
-        checkpointPath: expect.stringContaining(
-          "/root/cache/.canonical-recovery-checkpoint-",
-        ),
+        checkpointPath: expect.any(String),
         mcpLibrary: expect.objectContaining({
           kind: "prompthub-mcp-library",
           servers: [],
         }),
       }),
     );
+    const recoveryOptions = mocks.recoverCanonicalStorageAuthorityFromDatabase
+      .mock.calls[0]?.[0] as { checkpointPath?: unknown } | undefined;
+    const checkpointPath = String(recoveryOptions?.checkpointPath);
+    expect(path.dirname(checkpointPath)).toBe(path.join("/root", "cache"));
+    expect(path.basename(checkpointPath)).toMatch(
+      /^\.canonical-checkpoint-[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/u,
+    );
+    expect(path.basename(checkpointPath).length).toBeLessThanOrEqual(64);
     expect(mocks.createMcpResourceSecretStore).toHaveBeenCalledWith({
       filePath: "/root/secrets/mcp-resource-secrets.json",
       encryption,

spec/changes/active/database-resource-lifecycle-hardening/design.md

@@ -22,7 +22,9 @@ Canonical catalog, full-storage catalog, checkpoint verification/snapshot,
 catalog self-heal, file-authoritative recovery, and consistent-image failure
 paths use the database primitive. Checkpoint directory staging remains a
 separate bounded same-parent directory because it contains a complete tree, not
-only SQLite artifacts.
+only SQLite artifacts. Both automatic startup and selected-database recovery
+use the same `.canonical-checkpoint-<uuid>` target form; a recovery label or PID
+does not add another unbounded ancestor segment.
 
 No success-path data, schema, hash, quick-check, rename, or publication order
 changes.

spec/changes/active/database-resource-lifecycle-hardening/implementation.md

@@ -14,6 +14,8 @@ pending, so publication is not yet claimed.
 - The canonical checkpoint directory stage duplicated its long target basename,
   so bounded leaf filenames alone did not keep the complete SQLite path within
   budget.
+- The selected-database recovery caller still added a longer recovery label and
+  PID to its checkpoint ancestor after automatic startup had been bounded.
 - Task-owned database cleanup loops omitted `.lock` in Core, DB, and Desktop
   failure paths.
 - Cherry Studio and Hermes could leak an opened connection during schema
@@ -36,6 +38,8 @@ pending, so publication is not yet claimed.
 - Canonical startup now uses `.canonical-checkpoint-<uuid>` and checkpoint
   construction uses `.checkpoint-stage-<uuid>`, removing the long duplicated
   ancestor that still put a short SQLite leaf over the Windows budget.
+- Selected-database recovery now uses the same `.canonical-checkpoint-<uuid>`
+  target instead of `.canonical-recovery-checkpoint-<pid>-<uuid>`.
 - Cherry Studio and Hermes close stores rejected during schema validation;
   Cherry Skill closes capability-probe failures; NanoClaw closes its inbound
   database when its paired outbound database cannot open.
@@ -66,6 +70,8 @@ pending, so publication is not yet claimed.
   instrument source outside `packages/core`, so it reported 0 files for that
   cross-package helper despite all 10 tests executing; this tooling limitation
   is recorded rather than presented as numeric coverage.
+- The selected-database recovery checkpoint regression passed 6/6 tests after
+  the final audit finding; Desktop typecheck and focused ESLint passed.
 - Static Windows modeling with the release smoke's long root puts final
   verification/catalog-stage/post-publication verify paths at 198/194/199
   characters and their `.lock` paths at 203/199/204, respectively. The real

spec/changes/active/database-resource-lifecycle-hardening/proposal.md

@@ -27,6 +27,8 @@ weakness elsewhere.
   names and complete artifact cleanup.
 - Apply complete cleanup to canonical catalog/checkpoint/rebuild, safety-point,
   and file-authoritative recovery temporaries.
+- Remove avoidable checkpoint-directory amplification from both automatic
+  startup and selected-database recovery.
 - Close Cherry Studio, Hermes, and NanoClaw database handles on every validation
   and multi-open failure path.
 - Add failure, lock-artifact, path-boundary, and integration regressions.

spec/changes/active/database-resource-lifecycle-hardening/specs/database-lifecycle/spec.md

@@ -22,14 +22,23 @@ lock without the existing lease policy.
 
 PromptHub-owned temporary SQLite basenames MUST use a validated fixed label and
 a full UUID, remain at or below 64 characters, and not incorporate an arbitrary
-destination basename.
+destination basename. PromptHub-owned checkpoint ancestors that contain these
+databases MUST likewise use a bounded UUID form rather than adding operation
+names and process identifiers without a fixed budget.
 
 #### Scenario: caller provides an unsafe or oversized label
 
 - **When** a temporary database path is requested with traversal, separators,
   an empty value, or a label that would exceed the basename budget
 - **Then** path construction fails before creating a file
 
+#### Scenario: canonical recovery prepares a checkpoint
+
+- **When** automatic startup or selected-database recovery prepares a canonical
+  checkpoint
+- **Then** the checkpoint basename is bounded independently of the active root
+- **And** both flows use the same fixed-size UUID form
+
 ### `FR-DBLIFE-001`: External Session Store Validation Releases Handles
 
 Agent session adapters MUST close every SQLite handle they open when schema

spec/changes/active/database-resource-lifecycle-hardening/tasks.md

@@ -3,7 +3,8 @@
 - [x] `T-DBLIFE-001` (`NFR-DBLIFE-001`, `NFR-DBLIFE-002`,
       `DES-DBLIFE-001`, `TEST-DBLIFE-001`): add the bounded task-owned database
       primitive and adopt complete artifact cleanup across canonical, recovery,
-      checkpoint, and safety-point paths.
+      checkpoint, and safety-point paths, including bounded automatic and
+      selected-database recovery checkpoint ancestors.
 - [x] `T-DBLIFE-002` (`FR-DBLIFE-001`, `DES-DBLIFE-003`,
       `TEST-DBLIFE-003`): close Cherry Studio, Hermes, Cherry Skill, and NanoClaw
       handles on every validation and paired-open failure.

spec/changes/active/windows-canonical-authority-second-launch/design.md

@@ -19,13 +19,14 @@ the full checkpoint path. The catalog builder then uses
 - same parent directory as the destination
 - unchanged create, verify, rename, and SQLite sidecar cleanup sequence
 
-The startup checkpoint target uses `.canonical-checkpoint-<uuid>`, and
-`createCanonicalStorageCheckpoint()` uses `.checkpoint-stage-<uuid>` in the
-same parent. This removes the earlier target-basename duplication from every
-ancestor of the temporary SQLite catalogs. With the release smoke's long
-Windows runner profile, the resulting database and `.lock` paths retain
-explicit headroom below the VFS limit rather than relying on a short leaf name
-inside an already overlong directory.
+Startup and selected-database recovery checkpoint targets both use
+`.canonical-checkpoint-<uuid>`, and `createCanonicalStorageCheckpoint()` uses
+`.checkpoint-stage-<uuid>` in the same parent. This removes the earlier
+target-basename duplication from every ancestor of the temporary SQLite
+catalogs and avoids reintroducing a longer recovery-only ancestor. With the
+release smoke's long Windows runner profile, the resulting database and `.lock`
+paths retain explicit headroom below the VFS limit rather than relying on a
+short leaf name inside an already overlong directory.
 
 Naming is `O(1)` time and space. Catalog construction remains `O(B + R)` for
 canonical bytes and records; no additional scan, copy, database open, or
@@ -75,9 +76,9 @@ the required black-box coverage.
 
 - `TEST-WINCAT-001`: Core and Desktop filesystem/SQLite regressions capture the
   verification database and actual stage used for long checkpoint/catalog
-  destinations, including the checkpoint directory stage, and assert basename
-  budgets, sibling placement, target independence, successful publication, and
-  existing failure cleanup.
+  destinations, including startup/recovery checkpoint targets and the
+  checkpoint directory stage, and assert basename budgets, sibling placement,
+  target independence, successful publication, and existing failure cleanup.
 - `TEST-WINCAT-002`: Desktop unit/contract tests cover the release-only auto-exit
   guard, both signal orders, exactly-once exit, migration failure behavior, two
   launches, per-launch event boundaries, clean exit, and workflow blocking

spec/changes/active/windows-canonical-authority-second-launch/implementation.md

@@ -46,6 +46,10 @@ external-store handle findings are tracked separately in
   repeating the target basename. Under the deliberately long Windows release
   profile, the final verification, build-stage, and post-publication database
   lock paths model at 203, 199, and 204 characters rather than exceeding 260.
+- The database-wide follow-up found that selected-database recovery still used
+  `.canonical-recovery-checkpoint-<pid>-<uuid>`. Recovery now shares the bounded
+  `.canonical-checkpoint-<uuid>` form, so the same path amplification cannot
+  return outside normal startup.
 - The packaged Windows smoke keeps one deliberately long runner-owned profile
   for two launches. The first launch requires the upgrade safety snapshot,
   `waiting-renderer-migration`, and `window_ready`; the second reads only newly
@@ -101,6 +105,9 @@ basename.
   tests and Desktop 121/121 tests across release smoke, canonical publication,
   recovery, safety points, and affected external database adapters. DB, Core,
   and Desktop typechecks plus targeted Desktop ESLint passed.
+- The final selected-database recovery checkpoint regression passed 6/6 tests;
+  Desktop typecheck, focused ESLint, spec governance, and formatting passed
+  after the recovery-only ancestor was shortened.
 - The release-smoke lifecycle helper reached 100% statement, branch, function,
   and line coverage. Core canonical path/cleanup coverage reached 99.52%
   statements/lines, 98.37% branches, and 100% functions across the two touched

spec/changes/active/windows-canonical-authority-second-launch/proposal.md

@@ -31,9 +31,10 @@ detect a failure that appears when the same profile is opened again.
 - Keep canonical SQLite verification and stage filenames short and independent
   of the checkpoint/destination basename while preserving same-directory
   publication and atomic rename.
-- Keep the checkpoint target and its pre-publication directory stage bounded as
-  well; a short SQLite basename is insufficient when an internally amplified
-  parent path already consumes the Windows VFS budget.
+- Keep startup and selected-database recovery checkpoint targets, plus their
+  pre-publication directory stage, bounded as well; a short SQLite basename is
+  insufficient when an internally amplified parent path already consumes the
+  Windows VFS budget.
 - Preserve existing stage cleanup for create, quick-check, graph-hash, and
   destination-race failures.
 - Extend the packaged Windows x64 upgrade smoke to launch the same isolated