fix(web): don't round unrepresentable numbers, and reset app-switch drafts

Review round 2. Three findings, all real.

1. Precision. Mantine's `NumberInput` returns the raw *string* rather than
   a number once the value reaches `Number.MAX_SAFE_INTEGER` (see its
   `isValidNumber` guard), precisely because JS cannot hold it. Parsing
   that turned `90071992547409910` into `90071992547409904` and would
   have sent the server a number the user never typed. An inspector must
   not misreport what it transmits, so such input now reports no value —
   which is also what this field did before #1888, so nothing regresses.
   Only the integer part overflows, so long decimals stay parsed.

2. `AppDetailPanel` has the same reuse pattern as `ToolDetailPanel`:
   `AppsScreen.handleSelect` swaps `selectedAppName` + `formValues` in
   place without remounting, so switching between apps with a same-named
   number field could retain an equal-valued draft. It now passes
   `resetKey` too.

3. An exponent was never reachable: `NumberInput` masks input through
   `NumericFormat`, which rejects `e`. Dropped that claim from the doc
   comment rather than implying `"1e"` is a case being handled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0119LaPQ3v4NyBK3ZTdM9j84

clients/web/src/components/groups/AppDetailPanel/AppDetailPanel.tsx

@@ -76,6 +76,12 @@ export function AppDetailPanel({
           values={formValues}
           onChange={onFormChange}
           disabled={isOpening}
+          // Like ToolDetailPanel, this panel is reused across app selections
+          // rather than remounted (AppsScreen.handleSelect swaps
+          // selectedAppName + formValues in place), so the form needs the app
+          // tool's name to drop another app's in-progress field text. See
+          // SchemaFormProps.resetKey.
+          resetKey={tool.name}
         />
 
         <OpenAppButton