[rc2] Fix temporal table versioning when removing default constraints from columns

[Copilot]

Fixes #35631

Description
When using SQL Server temporal tables, removing a DEFAULT constraint failed as this requires versioning to be temporarily disabled.

Customer impact
Customers would get an exception when applying a migration that removes a DEFAULT constraint. Workarounds include avoiding removing DEFAULT constraints and disabling versioning manually.

How found
Customer reported on EF9.

Regression
Yes, from EF8.

Testing
Added test Temporal_table_with_default_constraint_can_alter_column that verifies temporal tables with DEFAULT constraints can have their columns altered successfully. Also added tests for other facets including HasDefaultValueSql.

Risk
Low. The change only affects migrations on temporal tables.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[AndriySvyryd]

@copilot Rewrite the PR summary using this template:

Fixes #{number}

**Description**
{Issue description}

**Customer impact**
{How does the reported issue affects customer's app? Are there workarounds?}

**How found**
{Was it customer reported or found during verification? How many customers are affected?}

**Regression**
{Is it a regression from a released version? Which one?}

**Testing**
{How the changes were tested}

**Risk**
{Low/Medium/High, argument why}

[AndriySvyryd]

@copilot Continue

[Copilot]

@copilot Rewrite the PR summary using this template:

...

Here's the PR summary rewritten using the template:

Fixes #35631

Description
When using SQL Server temporal tables, DEFAULT constraints were incorrectly being applied to both the main table and the history table during migrations. This caused subsequent column alterations to fail with constraint dependency errors like "The object 'DF__AHistory__Name__5DCAEF64' is dependent on column 'Name'". History tables in SQL Server temporal tables should not have DEFAULT constraints since they only store historical data and don't accept direct inserts.

Customer impact
Customers using SQL Server temporal tables with DEFAULT constraints on columns cannot perform subsequent migrations that alter those columns. The migration fails with a SqlException about constraint dependencies. Workarounds include manually dropping DEFAULT constraints from history tables before running migrations or avoiding DEFAULT constraints on temporal table columns entirely.

How found
This was customer reported via issue #35631. The issue affects any customer using SQL Server temporal tables with DEFAULT constraints who then tries to alter column properties in subsequent migrations.

Regression
This appears to be a long-standing issue in the temporal table implementation rather than a recent regression.

Testing
Added test Temporal_table_with_default_constraint_can_alter_column that verifies temporal tables with DEFAULT constraints can have their columns altered successfully. The fix was also manually verified to resolve the specific scenario described in the issue.

Risk
Low - The change is surgical and only affects the specific scenario where DEFAULT constraints were being incorrectly copied to history table operations. It preserves all other necessary annotations for proper history table operation.

@copilot Continue

Completed the requested tasks:

1. ✅ Added test for the DEFAULT constraint fix (commit e61598d)
2. ✅ Rewrote PR summary using the provided template format

The fix modifies CopyColumnOperation in SqlServerMigrationsSqlGenerator.cs to exclude RelationalAnnotationNames.DefaultConstraintName when copying annotations to history table operations, ensuring DEFAULT constraints are only applied to the main temporal table.

[artl93]

Low risk, customer reported