fix(chat): bound the sync copy path by the text limit, not the chip cap

Cursor Bugbot: writeLoadedRowsWithChip bailed once loaded rows exceeded
MAX_TABLE_SELECTION_ROWS, but buildTableSelectionContext already slices rowIds
to that cap. So selecting more than 500 loaded rows fell through to the async
path, which cannot carry a custom MIME, and silently lost the chip — while Add
to Chat on the very same selection still produced a 500-row chip.

The two limits govern different things: the chip's cap is how many rows a
table_selection can reference, the text's is TABLE_LIMITS.MAX_COPY_ROWS. Gate on
the latter. Past it the paged path still takes over, because it owns truncation
and the accompanying notice.

Author: waleedlatif1

apps/sim/app/workspace/[workspaceId]/tables/[tableId]/components/table-grid/table-grid.tsx

@@ -381,9 +381,15 @@ function writeLoadedRowsWithChip(opts: {
   context: ChatContext | null
 }): boolean {
   const { rows, context } = opts
-  if (!context || !opts.complete || rows.length === 0 || rows.length > MAX_TABLE_SELECTION_ROWS) {
-    return false
-  }
+  // Bounded by the TEXT limit, not the chip's row cap: `context` already slices
+  // itself to MAX_TABLE_SELECTION_ROWS, so a larger selection still copies in
+  // full here and carries a chip for as many rows as a chip can reference —
+  // matching what Add to Chat does with the same selection. Gating on the chip
+  // cap instead would drop the chip entirely on the async fall-through, which
+  // cannot carry a custom MIME. Past MAX_COPY_ROWS the paged path must take
+  // over, since it owns truncation and the notice that goes with it.
+  if (!context || !opts.complete || rows.length === 0) return false
+  if (rows.length > TABLE_LIMITS.MAX_COPY_ROWS) return false
   opts.clipboardData?.setData(
     'text/plain',
     rows.map((row) => opts.buildCells(row).join('\t')).join('\n')