fix: strip system SAs from V1→CHASM schedule migration state

[chaptersix]

Summary

When a V1 scheduler workflow is migrated to CHASM, its raw search attributes (including system SAs like TemporalNamespaceDivision and TemporalSchedulePaused) were copied verbatim into the CHASM entity's CustomSearchAttributes store. The visibility task executor then iterated these and routed each one through the custom SA mapper. System SAs have no per-namespace mapping, so the mapper returned an error and emitted a spurious warn-level log:

"Failed to get field name for alias, ignoring search attribute"
alias="TemporalNamespaceDivision"
error="Namespace <ns> has no mapping defined for search attribute TemporalNamespaceDivision"

The log was benign — TemporalNamespaceDivision is overwritten with the archetype ID unconditionally afterward, and TemporalSchedulePaused is set from Schedule.State.Paused by Scheduler.SearchAttributes(). But system SAs have no business being in the custom SA store.

Fix

In LegacyToCreateFromMigrationStateRequest (chasm/lib/scheduler/migration/migration.go), filter out reserved/system SAs before they enter SchedulerMigrationState.SearchAttributes using sadefs.IsReserved. This covers all current and future system SAs without needing a hardcoded list.

Tests

• Unit test (migration_test.go): TestLegacyToCreateFromMigrationStateRequest_StripsSystemSearchAttributes — verifies TemporalNamespaceDivision and TemporalSchedulePaused are stripped while user-defined SAs are preserved.
• Functional test (schedule_migration_test.go): TestScheduleMigrationV1ToV2_SearchAttributesAfterMigration — creates a paused V1 schedule (so the V1 workflow stamps both system SAs), migrates to CHASM, then asserts:
  • Custom SAs survive migration
  • System SAs are absent from the CHASM entity's custom SA store
  • TemporalSchedulePaused = true is correctly queryable in visibility (framework manages it from live state)