.NET: Preserve table state after declarative EditTable Add

[KXHXK]

Motivation & Context

Declarative EditTable and EditTableV2 currently replace their items variable with the newly added record after an Add operation. A second Add then fails because the variable is no longer a table. This change keeps the mutated table bound to the variable so repeated additions work as expected.

AI assistance was used for codebase analysis and test scaffolding. The final implementation, diff, and validation results were reviewed by KXH.

Description & Review Guide

• What are the major changes? Assign the mutated TableValue after Add in both executors; update existing Add assertions; add regression tests that execute two consecutive additions and verify row order.
• What is the impact of these changes? Declarative workflows can add multiple records to the same table without losing the table binding. Update and delete behavior is unchanged.
• What do you want reviewers to focus on? The post-Add assignment semantics in both executor versions and whether the updated assertions capture the intended state contract. Validation: 841 tests passed on net10.0, 841 tests passed on net472, the declarative project built across all target frameworks with 0 warnings/errors, and dotnet format --verify-no-changes passed.

Related Issue

Fixes #7323

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add [BREAKING] to the title prefix, before or after any language prefix) - a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Fixes a bug in the .NET declarative workflow EditTable/EditTableV2 executors where Add overwrote the bound items variable with the newly-added RecordValue, causing subsequent Add operations to fail because the variable was no longer a table.

Changes:

• Update EditTableExecutor and EditTableV2Executor to re-assign the mutated TableValue back to the itemsVariable after AppendAsync.
• Update existing unit tests to assert that the variable remains a table after Add.
• Add regression tests for consecutive Add operations that verify the final table contents and row order.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
dotnet/src/Microsoft.Agents.AI.Workflows.Declarative/ObjectModel/EditTableExecutor.cs	Preserve table binding by assigning tableValue (not the new record) back to the items variable after Add.
dotnet/src/Microsoft.Agents.AI.Workflows.Declarative/ObjectModel/EditTableV2Executor.cs	Same table-preserving assignment semantics for the V2 executor after Add.
dotnet/tests/Microsoft.Agents.AI.Workflows.Declarative.UnitTests/ObjectModel/EditTableExecutorTest.cs	Update assertions to expect a table result and add a consecutive-add regression test.
dotnet/tests/Microsoft.Agents.AI.Workflows.Declarative.UnitTests/ObjectModel/EditTableV2ExecutorTest.cs	Update assertions to expect a table result and add a consecutive-add regression test validating order.

[KXHXK]

@microsoft-github-policy-service agree