Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@web/apps/dashboard/app/`(app)/[workspaceSlug]/projects/[projectId]/(overview)/settings/components/advanced-settings/openapi-spec-path.tsx:
- Around line 41-53: The change detection compares the raw watched value
(current) against defaultValue but the submit handler trims input (trimmed)
before saving, causing whitespace-only edits to appear changed; update the
comparison used to compute hasChanges to use the same normalization as onSubmit
(e.g., compute a normalizedCurrent by trimming current and normalizing empty
string to null/empty the same way defaultValue is normalized) so hasChanges
reflects the same trimmed value logic as onSubmit (refer to useWatch/current,
hasChanges, onSubmit, openapiSpecPathSchema, and trimmed).

In
`@web/apps/dashboard/lib/trpc/routers/deploy/environment-settings/runtime/update-openapi-spec-path.ts`:
- Around line 9-12: The input allows an empty string for openapiSpecPath which
should be canonicalized to null; update the API boundary to normalize empty or
whitespace-only values to null before persisting. Locate the z.object schema
that defines openapiSpecPath and the request handler (the
update-openapi-spec-path procedure or function that reads openapiSpecPath) and
either: (a) add a transform on the schema for openapiSpecPath to map "" or
all-whitespace to null (e.g., transform/union pattern instead of plain
z.string().max(512).nullable()), or (b) immediately after parsing the input in
the handler, set openapiSpecPath = openapiSpecPath?.trim() === "" ? null :
openapiSpecPath before any validations/DB writes so only null represents
“disabled.” Ensure the persisted value and any downstream logic use this
normalized null form.

---

Outside diff comments:
In
`@web/apps/dashboard/app/`(app)/[workspaceSlug]/projects/[projectId]/(overview)/openapi-diff/page.tsx:
- Around line 26-55: The effect is overwriting user selections and preserving
stale URL-driven state because it only applies params when both from and to
exist, returns early (keeping stale values) and later re-applies
currentDeploymentId even after a user picked a baseline; update the useEffect to
1) treat fromParam and toParam independently (validate each against
sortedDeployments and call setSelectedFromDeployment/setSelectedToDeployment
only for the valid param rather than requiring both), 2) remove the
unconditional early return so a valid single param won’t block fallback logic,
and 3) avoid re-applying currentDeploymentId if a user has already selected a
baseline by checking selectedFromDeployment/selectedToDeployment (or only run
the fallback when neither selection exists) before calling
setSelectedFromDeployment with currentDeploymentId; reference the useEffect,
searchParams, fromParam, toParam, sortedDeployments, currentDeploymentId,
setSelectedFromDeployment and setSelectedToDeployment symbols when making these
changes.