docs(options): the EDIT limits truncate the grid and warn

getdata no longer refuses a selection over DC_MAXOBS_WEBEDIT or
DC_MAXCELLS_WEBEDIT - it serves the rows within the limit and flags the
truncation against the table name.  Update the option reference and the two
developer-guide pages that claimed the edit screen stops with "Table is too
big".  The hook page also carried the old 500 row default.

docs/dcc-options.md

@@ -23,6 +23,8 @@ Set to YES or NO to enable email alerts. This requires email options to be preco
 ### DC_MAXCELLS_WEBEDIT
 By default, a maximum of 200,000 cells (observations multiplied by variables) can be edited in the browser at one time.  This limit is applied together with [DC_MAXOBS_WEBEDIT](#dc_maxobs_webedit) - whichever is reached first.
 
+A selection over either limit is served truncated: the grid carries the rows that fit, and a warning triangle next to the table name names the limit that was reached.  Filter the table to see the rest.
+
 The cell count matters because the cost of an EDIT screen load tracks the number of cells, not the number of rows.  A 10 column table is comfortable at 250 rows, but 250 rows of a 1000 column table is 250,000 cells.
 
 ### DC_MAXOBS_WEBEDIT

docs/developer-guide/filter-pre-edit-hook.md

@@ -146,7 +146,7 @@ The user's clause and Data Controller's clause have to be kept apart, because Ro
 
 ## The row cap
 
-`getdata` refuses a result larger than `DC_MAXOBS_WEBEDIT` (500 by default) with *Table is too big*. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap. Check the count before handing the data back, or raise the option for that table in `MPE_CONFIG`.
+`getdata` truncates a result larger than `DC_MAXOBS_WEBEDIT` (250 by default) or `DC_MAXCELLS_WEBEDIT` to the rows within the limit, and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap - the rows past the limit never reach the browser. Check the count before handing the data back, or raise the option for that table in `MPE_CONFIG`.
 
 ## Matching the filter chips
 

docs/developer-guide/two-rule-sets-one-table.md

@@ -109,7 +109,7 @@ From that moment the changeset is an approval against `ORDERS.ORDERS`. The appro
 ### Other things to watch
 
 - Concurrency behaves correctly here. Both mirrors route their submit to the same base table, so every approval locks, loads and logs against one identity - unlike the two-libref route above.
-- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap will stop the edit screen with "Table is too big". [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
+- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap truncates the edit screen, with a warning against the table name. [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
 - The hook's output must have the same columns the editor expects - the real table, minus any transaction or processing columns that Data Controller drops on load.
 - The real table must itself be registered in `MPE_TABLES`. The approval screen resolves the table's audit settings from that row, so a changeset routed to a table with no registration cannot be reviewed - the submit is refused up front, naming the table.
 - The mirror's `MPE_TABLES` row is read for the edit screen and the real table's for the load, so keep their `buskey`, `loadtype` and temporal column settings identical.