docs(url-path): drop the false claim that widening restores prior behaviour

The module TSDoc said the number/bigint widening fixed 'a regression for the
call sites whose pre-guard form was a bare ${params.id} template that
stringified a number fine'. It did not. Every pre-guard form in a422990
used .trim() (`/v13/deployments/${params.deploymentId.trim()}`,
`sandboxId?.trim()`), so a numeric id threw there too - no importer has ever
accepted one. The cited examples were also wrong: only Vercel and Daytona
import this module, and neither Box nor X does.

Replaced with the real motivation - params are declared type: 'string' but
nothing enforces it before the guard, and the old coercion-to-'' turned a
supplied numeric id into a misleading 'is required'. Two test comments made
the same claim ('still stringifies', 'replaced bare ${params.id} templates')
and are corrected; no assertion is weakened.

Author: waleedlatif1

apps/sim/tools/url-path.test.ts

@@ -124,9 +124,10 @@ describe('safeUrlPathSegment', () => {
 })
 
 /**
- * The guard replaced bare `${params.id}` templates at call sites where a
- * numeric-looking id (Stripe `id`, Spotify ids, X `woeid`) could arrive as a
- * JSON number. Coercing a non-string to `''` reported it as missing.
+ * Tool params are declared `type: 'string'` but nothing enforces that before
+ * the value reaches the guard: an LLM tool call or stored workflow state can
+ * hand a numeric-looking id over as a JSON number. Coercing a non-string to
+ * `''` reported such a value as missing, which names the wrong problem.
  */
 describe('non-string inputs', () => {
   it.concurrent.each([
@@ -318,8 +319,11 @@ describe('exponential number spellings', () => {
 
 /**
  * The 44 live call sites (Vercel x43, Daytona x1) pass provider ids and
- * hostnames as strings, occasionally a numeric id. Their output must be
- * byte-identical across this change.
+ * hostnames, and every one of them interpolated `${params.id.trim()}` before
+ * these guards existed — so a string is the only shape any of them has ever
+ * handled, and a string's output must stay byte-identical across this change.
+ * A numeric id is the newly accepted shape, not a restored one: it threw
+ * `TypeError: .trim is not a function` at those same call sites before.
  */
 describe('live call-site values', () => {
   it.concurrent.each([
@@ -336,8 +340,8 @@ describe('live call-site values', () => {
     expect(safeUrlPathSegment(value, 'id')).toBe(value)
   })
 
-  it.concurrent('still stringifies a numeric id', () => {
-    expect(safeUrlPathSegment(2487956, 'woeid')).toBe('2487956')
-    expect(safeUrlPathSegment(0, 'folderId')).toBe('0')
+  it.concurrent('stringifies a numeric id these call sites used to reject', () => {
+    expect(safeUrlPathSegment(2487956, 'deploymentId')).toBe('2487956')
+    expect(safeUrlPathSegment(0, 'sandboxId')).toBe('0')
   })
 })

apps/sim/tools/url-path.ts

@@ -39,14 +39,20 @@
  * Trimming is left to the caller, because whether surrounding whitespace is
  * copy-paste noise or part of the value is a per-helper decision.
  *
- * Tool params are declared `type: 'string'`, but the value arrives from an LLM
- * tool call or user input and a numeric-looking id (a Box `folderId`, whose
- * root folder is literally `0`; an X `woeid`) can land as a JSON **number**.
- * The previous `typeof value === 'string' ? value.trim() : ''` turned any such
- * value into `''`, which the guards then reported as *"<param> is required"* —
- * a confusing error for a value the caller did supply, and a regression for
- * the call sites whose pre-guard form was a bare `${params.id}` template that
- * stringified a number fine.
+ * Tool params are declared `type: 'string'`, but that declaration is not
+ * enforced anywhere before the value reaches here: it arrives from an LLM tool
+ * call or from stored workflow state, where a numeric-looking id (a Vercel
+ * `deploymentId`, a Daytona `sandboxId`) can be serialized as a JSON **number**
+ * and stays one. The previous `typeof value === 'string' ? value.trim() : ''`
+ * turned any such value into `''`, which the guards then reported as
+ * *"<param> is required"* — the least actionable message available for a value
+ * the caller did supply, and one that points at the wrong fix.
+ *
+ * This is not a restoration of prior behaviour. Every call site that predates
+ * these guards interpolated `${params.id.trim()}`, so a numeric id threw
+ * `TypeError: params.id.trim is not a function` there too. The widening is a
+ * deliberate improvement: it accepts what callers actually send, and where it
+ * still refuses (below) it says why by name.
  *
  * An id too large for a `double` — a Discord snowflake, a Twitter id — is
  * **not** in scope here and cannot be: `JSON.parse` destroys the precision