A failed inline grid edit clears pending changes and reports Changes Applied

## What

When an inline grid edit fails, the UI resets as if it had succeeded. The pending-change state is cleared, EDIT mode turns itself off, and a "Changes Applied" toast is shown, regardless of what the statements did.

## Where

src/hooks/use-inline-editing.ts:150-164

```ts
for (const statement of statements) {
await executeQuery(statement.sql, undefined, false, {
skipSafety: true,
...(statement.params.length > 0 && { params: statement.params }),
});
}
setPendingChanges([]);
setEditingEnabled(false);
toast({
title: "Changes Applied",
description: `${statements.length} UPDATE statement(s) submitted; check the results panel for each row.`,
});
```

`executeQuery`'s return value is never read. Nothing branches on whether any statement succeeded, so the three lines after the loop run in every case.

## Observed

Applying an edit that the engine rejected with `column "product_id" does not exist` (HTTP 400): the pending-change badge disappeared, EDIT mode switched off, the cell reverted to its old value, and the only record of the failure was the audit trail.

The toast wording is careful, it says "submitted" rather than "executed" and points at the results panel. But the state reset around it says the opposite, and the title says "Changes Applied".

## Why this matters

A user who edited five cells and had all five rejected sees the same end state as a user whose five edits all landed. The pending changes are gone, so the work cannot be retried from the grid.

## Suggested direction

Read what `executeQuery` returns, count the statements that failed, and branch: keep the pending changes and stay in EDIT mode when nothing applied, or report the partial count when some did. The toast text can then be honest about the outcome instead of about the submission.

## Note

Verified from source. Whether `executeQuery` raises its own error toast on this specific path (single statement, `skipSafety`, with params) was observed as "no toast appeared" during testing but not traced through the code, so that half of the report is an observation rather than a reading.

## Related

Issue for the wrong-table UPDATE filed separately.

Start in src/hooks/use-inline-editing.ts:150-164 and trace the return value of executeQuery, including the skipSafety and params path. Verify how failed and partially successful statements are reported, then preserve pending changes and EDIT mode when none apply, or report the partial count when some do. Confirm the toast reflects the actual outcome.

Written by the indexing model from the issue text.