Fix missing WHERE clause in DWSql upsert UPDATE branch

[naxing123]

The dwsql (Azure Synapse) upsert builder emitted an UPDATE with no WHERE clause, so a single PUT upsert hitting the existing-row UPDATE branch overwrote every row in the target table and dropped the update DB policy (CWE-862).

Append WHERE {pkPredicates AND update DB policy} to the UPDATE branch, mirroring MsSqlQueryBuilder.Build(SqlUpsertQueryStructure) and the DWSql PATCH path. Add a regression test asserting the generated dwsql upsert UPDATE branch is scoped by the PK and the update database policy.

Why make this change?

Fixes a security defect (CWE-862, missing row scoping / authorization) in the Azure Synapse Analytics (dwsql / Dedicated SQL Pool) upsert query builder.
The dwsql upsert builder computed pkPredicates but never appended a WHERE clause to the generated UPDATE. As a result, any authenticated user with entity-level update permission could issue a single [PUT /api//] that hit the existing-row UPDATE branch and overwrite every row in the target table, while also silently discarding the row-level update database policy. The API still returns a normal single-record 200, so the mass overwrite is indistinguishable from a legitimate single-row update in application logs.
Not affected: the MSSQL/PostgreSQL/MySQL upsert builders and DAB's own DWSql PATCH path ([Build(SqlUpdateStructure)]), which all correctly scope the UPDATE with WHERE.

What is this change?

• Summary of how your changes work to give reviewers context of your intent.
  Append WHERE {pkPredicates AND update DB policy} to the UPDATE branch, mirroring MsSqlQueryBuilder.Build(SqlUpsertQueryStructure) and the DWSql PATCH path. Add a regression test asserting the generated dwsql upsert UPDATE branch is scoped by the PK and the update database policy.

How was this tested?

• Integration Tests
• Unit Tests
• Manual tests
  I have verified manually against a live Fabric Warehouse/dwsql instance. Ran a PUT upsert through DAB REST e2e and confirmed via direct SQL that only the targeted row changed and the change persisted. I also removed the fix/WHERE clause and confirmed a single PUT then overwrote all rows in the table, reproducing CWE-862, which the fix prevents.

Sample Request(s)

Given a dwsql entity Book (PK id) with update permission granted, the following existing-row upsert previously overwrote all rows:
PUT /api/Book/id/7
Content-Type: application/json

{
"title": "The Hobbit Returns to The Shire",
"publisher_id": 1234
}

Generated UPDATE branch before the fix (overwrites every row):
IF @ROWS_TO_UPDATE = 1 BEGIN UPDATE [dbo].[books] SET [title] = @param1, [publisher_id] = @Param2 END

Generated UPDATE branch after the fix (scoped to the target row and update policy):
IF @ROWS_TO_UPDATE = 1 BEGIN UPDATE [dbo].[books] SET [title] = @param1, [publisher_id] = @Param2 WHERE [dbo].[books].[id] = @param0 END

[Copilot]

Pull request overview

Fixes a critical security defect in the DWSQL (Azure Synapse) upsert query builder where the UPDATE branch could be emitted without a WHERE clause, potentially overwriting all rows and bypassing update DB policy scoping.

Changes:

• Scope the DWSQL upsert UPDATE branch using WHERE {pkPredicates AND updateDbPolicy} (mirrors the MsSql upsert builder behavior).
• Add a unit regression test asserting the DWSQL upsert UPDATE branch includes WHERE, the PK predicate, and the update DB policy predicate.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Core/Resolvers/DWSqlQueryBuilder.cs	Adds WHERE scoping to the DWSQL upsert UPDATE branch using PK + update DB policy predicates.
src/Service.Tests/UnitTests/DwSqlQueryBuilderUpsertTests.cs	Adds a regression unit test to ensure DWSQL upsert UPDATE is always scoped by PK and update DB policy.

[Aniruddh25]

Needs some clarifications.

[Aniruddh25]

Please resolve copilot suggestions.