fix: normalize chains JSON keys during plan phase (OKTA-1184047)

[aditya-okta]

Problem: When a user configures chains with jsonencode({...}) where HCL attribute order puts userVerification before method, Terraform preserves that source ordering in the JSON string. After apply, the
provider's Read path calls NormalizeDataJSON which re-marshals the chain through a Go map — sorting all keys alphabetically. The Framework then compares the planned value (non-alphabetical key order)
against the post-apply state value (alphabetical key order) and raises:

Error: Provider produced inconsistent result after apply
.rule[1].chains[0]: was cty.StringVal("{..."userVerification":"OPTIONAL","method":"push"...}"),
but now cty.StringVal("{..."method":"push","userVerification":"OPTIONAL"...}")

Soln: Add ChainsPlanModifier, a planmodifier.List on the chains attribute that normalizes JSON key order during the plan phase, before apply. This makes the planned value match the post-apply state value
that NormalizeDataJSON on Read already produces.

The modifier validates each chain string with json.Unmarshal and surfaces an AddAttributeError diagnostic for invalid JSON rather than silently corrupting the value to "{}".

Changes

• resource_okta_app_signon_policy_rules.go — new ChainsPlanModifier wired into the chains schema attribute's PlanModifiers
• resource_okta_app_signon_policy_rules_test.go — unit test (TestChainsPlanModifier) covering sorted keys, unsorted keys, nested structures, and invalid JSON; acceptance test
  (TestAccResourceOktaAppSignOnPolicyRules_chains_misaligned_keys) with a PlanOnly idempotency step that would have failed before the fix
• examples/resources/okta_app_signon_policy_rules/chains_misaligned_keys.tf — example config reproducing the customer scenario
• test/fixtures/vcr/idaas/.../oie-00.yaml — VCR cassette for the acceptance test

[dhiwakar-okta]

Approved with comments.