New-UDTable does not apply refreshed -InitialState when the table ID is unchanged

I reproduced this on a PowerShell Universal dashboard page at `/test`.

`New-UDTable -InitialState` accepts an initial state containing `Search`, `Filters`, `OrderBy`, and `PageSize`. However, when a table is recreated inside a synced `New-UDDynamic` with the same table ID, the refreshed `InitialState` is emitted by the server but is not reflected in the existing client-side table UI.

Minimal reproduction

```powershell
New-UDPage -Name 'Test' -Url '/test' -Content {
New-UDButton -Text 'Apply Bob state' -OnClick {
$Page:testCasesBulkNoteTableState = @{
Search = 'bob'
Filters = @(
@{
id = 'name'
value = '-2'
}
)
OrderBy = @{}
PageSize = 12
}

Sync-UDElement -Id 'testClearFilterDynamic'
}

New-UDDynamic -Id 'testClearFilterDynamic' -Content {
$tableState = $Page:testCasesBulkNoteTableState

New-UDTable -Id 'table7' `
-Data @(
[pscustomobject]@{ Name = 'Alice - 1' }
[pscustomobject]@{ Name = 'Bob - 2' }
) `
-Columns @(
New-UDTableColumn -Property 'Name' -Title 'Name' -Id 'name'
) `
-ShowSearch `
-InitialState $tableState
}
}
```

Expected behavior

After clicking **Apply Bob state**, syncing the enclosing `New-UDDynamic` should cause the same-ID table to apply the newly rendered `InitialState`:

```json
{
"Filters": [{ "value": "-2", "id": "name" }],
"PageSize": 12,
"OrderBy": {},
"Search": "bob"
}
```

In particular, the search input should show `bob`, and the state should apply in the same way as a table initially mounted with that payload.

Actual behavior

On first render, `$Page:testCasesBulkNoteTableState` is `$null`, so `table7` mounts with an empty search input.

After the button assigns the state and calls `Sync-UDElement` on the enclosing dynamic region:

- Server-side instrumentation shows the recreated `New-UDTable` component emits the exact `initialState` JSON above.
- The post-sync payload is byte-for-byte identical to a separately mounted hard-coded control table that displays `bob`.
- With the stable table ID `table7`, the original search input node remains connected after the dynamic sync and remains blank.
- The updated `InitialState` is therefore not applied to the existing same-ID client table.

Changing only the child table ID after the click, for example from `table7-r0` to `table7-r1`, forces a new mount and the search input correctly displays `bob`.

Confirmed observations

The reproduction ruled out:

- `$Page:` scope availability after the click
- Hashtable versus ordered hashtable / JSON serialization behavior
- Filter ID casing; the final state uses `name`, matching the column ID
- A mismatch in the emitted `initialState` payload
- Syncing the table directly; only the enclosing `New-UDDynamic` can be synced in this scenario

Request

Could PSU provide a supported mechanism for a same-ID `New-UDTable` to apply a refreshed `InitialState` when its enclosing `New-UDDynamic` is synced?

Alternatively, an explicit supported client-state update API for `New-UDTable` would address this use case.

Changing the table ID is not a practical workaround because it resets the table's client state and uses component identity as a forced refresh rather than applying the intended updated state.

Workaround

The current workaround is to maintain a page-scoped revision and include it in the child table ID, incrementing that revision immediately before syncing the enclosing `New-UDDynamic`:

```powershell
$Page:testCasesBulkNoteTableRevision = [int]$Page:testCasesBulkNoteTableRevision + 1
Sync-UDElement -Id 'testClearFilterDynamic'

New-UDDynamic -Id 'testClearFilterDynamic' -Content {
$revision = [int]$Page:testCasesBulkNoteTableRevision

New-UDTable -Id "table7-r$revision" `
-InitialState $Page:testCasesBulkNoteTableState `
# existing columns and load-data configuration
}
```

For example, the table ID changes from `table7-r0` to `table7-r1` when applying the preset state. This forces the client to mount a fresh table and causes `Search = 'bob'` to appear. It is a functional workaround, but it discards existing client-side table state, so it should not be required for a same-ID refreshed `InitialState`.