Fixes #13735

Problem

The readLocalFile tool accepts a loc: [startLine, endLine] parameter to read a specific line range. However, when called through the Desktop Electron runtime, the loc parameter was always ignored — the returned content always started from line 0.

Root cause: A parameter conversion mismatch in LocalSystemExecutionRuntime.denormalizeParams.

The call chain is:

1. LocalSystemExecutor.readLocalFile(params) → extracts loc → passes {startLine, endLine, path} to runtime.readFile()
2. ComputerRuntime.readFile() → calls callService('readLocalFile', {startLine, endLine, path})
3. LocalSystemExecutionRuntime.denormalizeParams('readLocalFile', ...) → fell through to default → passed {startLine, endLine, path} unchanged to the IPC service
4. IPC handler LocalFileCtr.readFile() expects LocalReadFileParams with loc?: [number, number], not startLine/endLine
5. Since loc was undefined, readLocalFile defaulted to [0, 200] on every call

Solution

Added an explicit readLocalFile case in denormalizeParams that reconstructs the loc tuple from startLine and endLine before forwarding to the IPC layer:

case 'readLocalFile': {
  const loc: [number, number] | undefined =
    params.startLine !== undefined || params.endLine !== undefined
      ? [params.startLine ?? 0, params.endLine ?? 200]
      : undefined;
  return { fullContent: params.fullContent, loc, path: params.path };
}

When neither startLine nor endLine is provided, loc is undefined, which causes the readLocalFile backend to use its own default of [0, 200] — preserving existing behavior.

Testing

• Verified with existing unit tests in packages/local-file-shell/src/file/__tests__/file.test.ts and apps/desktop/src/main/controllers/__tests__/LocalFileCtr.test.ts that the underlying readLocalFile correctly slices lines when loc is provided
• The fix closes the gap where loc was never reaching the file-reading layer