[J2TeamNNL]

Summary

• The grid edits rows of a view on PostgreSQL, MySQL, MariaDB and SQL Server when the server writes through it without a rule or an INSTEAD OF trigger, and the view shows every primary key column of the one table it reads. Edits go to the view, keyed on the view columns that show that key.
• New PluginKit requirement fetchViewRowEditing(view:schema:), default nil, so other engines keep views read-only. It answers .editable(PluginViewWriteTarget) (base table, key, read-only columns, base column defaults and identity, allowed operations) or .readOnly(reason). One shared PluginViewRowEditing.resolve builds the target for every engine. Kit 41 has not shipped, so the version stays.
• PostgreSQL: pg_relation_is_updatable bits per operation, pg_column_is_updatable per column, the _RETURN target list followed through nested views; any rule or INSTEAD OF trigger makes the view read-only.
• MySQL and MariaDB: IS_UPDATABLE and the stored definition, tokenized by Unicode scalar, items mapped to view columns by position, nested views followed, the key read from STATISTICS (column grants hide part of it from KEY_COLUMN_USAGE). MySQL inserts only when every view column is a base column; MariaDB inserts past computed columns. TiDB, OceanBase and Databend stay read-only.
• SQL Server: WITH VIEW_METADATA and INSTEAD OF triggers on the view chain are read-only, browse mode maps columns, compile-only probes decide each operation (4405 on DELETE marks a join, self-joins included), the base key and columns are read in the base table's database.
• A read-only view says why in the grid's tooltip, in table tabs too. A query tab or deep-linked tab reading a view gets the same gate, and a failed check keeps a known view read-only.
• Computed and server-owned view columns are never written. Add Row, Duplicate and Paste need insert; Delete and Undo Delete need delete. A new row takes the base table's defaults and identity.
• Cascade delete preview roots on the base table, or says it could not check when that table is in another database.
• Data Rewind refuses a row deleted through a view and a row a filtered view no longer shows; the stored record stays readable by 0.83 and refuses there too.
• Keyed writes SQL Server's driver sends through a view are held to one row, as the other engines' already are.
• A save through a view reloads tabs on its base table, and a change to the base table reloads view tabs.
• PluginSQLFilter moved to its own file, so PluginDatabaseDriver.swift stays under SwiftLint's length limit unsqueezed.

Test plan

• PluginViewRowEditingTests and MSSQLViewSourcesTests (swift test); PostgreSQLViewRowEditingTests and MySQLViewRowEditingTests on fixtures read from live servers.
• Hosted UpdatableViewRowWriteTests: tooltip in a table tab, insert and delete gating, stale keys refused, the base table in the save plan. New cases in ResultEditabilityTests, TabObjectKindTests, ParseSchemaMetadataTests, CascadeDeletePlanTests, RewindPlannerTests, RowWriteOperationBuilderTests, RowChangeStatementFactoryCoverageTests.
• apple/scripts/probes/check-view-row-editing.sh builds the drivers' own view code, checks each answer and writes through every editable view: PostgreSQL 17 (47 checks), MySQL 8.4 (50), MariaDB 11.8 (50), SQL Server 2022 (47), all passed.

	Light	Dark
Before: a view is read-only, with no reason given
After: an edit staged through an updatable view
After: a view that hides its key says why

Docs: TableProApp/docs#148 (draft, merges after this).

Fixes #3934