fix(db): idempotent migration script runs clean on SQL Server (#126)

`dotnet ef migrations script --idempotent` puts each migration in ONE batch
behind IF NOT EXISTS guards, and SQL Server compiles the whole batch before any
guard runs. AddAuditLogHashChain adds ChainSeq and then creates two filtered
indexes whose WHERE clause references it in the same batch, so the script
failed with Msg 207 "Invalid column name 'ChainSeq'" on any DB at migration
<= 60 (the 2026-11-11 vd03 deploy hand-inserted GO separators instead).

- AddAuditLogHashChain: the two CREATE INDEX statements go through EXEC(N'...')
  so they compile at execution time. Same indexes, same snapshot; Migrate() /
  database update unaffected; DBs that already ran the migration never run it
  again. The column-level GRANT compiles fine (checked at execution).
- Audit of 58-64: no other migration hits the pattern (the idempotent script
  from 57 now runs clean end to end; AddConfigGraphRowVersions' plain CREATE
  INDEX on a new column is not compile-checked).
- docs/plans/sql/AddAuditLogHashChain.sql: same EXEC wrap. It, and
  PrefixSearchIndexes.sql / AddConfigGraphRowVersions.sql, also carried a
  stray UTF-8 BOM after the prepended header comment that made sqlcmd fail
  with Msg 102 on line 1 of the batch; removed.
- New IdempotentMigrationScriptTests: migrates the fixture DB to 57, runs the
  generated idempotent script batch by batch, asserts every migration applied,
  then re-runs it as a no-op. Fails with Msg 207 without the migration fix.

Co-Authored-By: Claude <noreply@anthropic.com>

src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/Migrations/20261109211317_AddAuditLogHashChain.cs

@@ -77,17 +77,24 @@ namespace ZB.MOM.WW.ScadaBridge.ConfigurationDatabase.Migrations
 
             // AuditLog is monthly-partitioned with a partition-switch purge, so both indexes
             // MUST be partition-aligned (same pattern as ReviewRemediationIndexes).
+            //
+            // Both statements reference ChainSeq, which this same migration adds. The
+            // `dotnet ef migrations script --idempotent` output puts a whole migration in ONE
+            // batch, and SQL Server compiles the batch before any IF guard runs — so a direct
+            // reference to the not-yet-existing column fails with Msg 207 (ScadaBridge#126).
+            // EXEC defers compilation to execution time, after the ADD COLUMN has run. The
+            // resulting indexes are identical; `database update` / Migrate() are unaffected.
             migrationBuilder.Sql(@"
-CREATE NONCLUSTERED INDEX IX_AuditLog_Unchained
+EXEC(N'CREATE NONCLUSTERED INDEX IX_AuditLog_Unchained
 ON dbo.AuditLog (OccurredAtUtc, EventId)
 WHERE ChainSeq IS NULL
-ON ps_AuditLog_Month(OccurredAtUtc);");
+ON ps_AuditLog_Month(OccurredAtUtc);');");
 
             migrationBuilder.Sql(@"
-CREATE NONCLUSTERED INDEX IX_AuditLog_ChainSeq
+EXEC(N'CREATE NONCLUSTERED INDEX IX_AuditLog_ChainSeq
 ON dbo.AuditLog (ChainSeq)
 WHERE ChainSeq IS NOT NULL
-ON ps_AuditLog_Month(OccurredAtUtc);");
+ON ps_AuditLog_Month(OccurredAtUtc);');");
 
             migrationBuilder.Sql(@"
 IF DATABASE_PRINCIPAL_ID('scadabridge_audit_chainer') IS NULL