…olumn (#7412)

The update API rejects nested column references (`set` errors on a `.`
in the column name), so a nested field can only be changed by setting
its whole **top-level struct column** (e.g. `SET s = named_struct('x',
…)`).

`commit_impl` built `fields_for_preserving_frag_bitmap` from the struct
column's own (parent) field id via `field_id(column_name)`, so an index
on a nested **child** field (a different leaf id) was absent from the
set. `register_pure_rewrite_rows_update_frags_in_indices` then wrongly
extended that child-field index over the rewritten fragment, which was
therefore treated as indexed and never re-scanned — so the updated rows
were silently dropped from queries on the index (false negatives).

The fix collects the full field subtree of each updated column, so a
struct-column update marks all descendant field ids as modified. Flat
columns are unaffected (no children).

This is the SQL `UPDATE` counterpart of the merge_insert fix in
#7410. Adds a regression test
(`test_update_struct_column_keeps_nested_index`): a BTree index on
`s.x`, an update of the struct column `s`, and an assertion that the
index's effective fragment bitmap is not extended over the rewritten
fragment so the updated value is still found.