fix(push_group): save state after deactivating during delete

[exitcode0]

Fixes #2903

Delete for okta_push_group makes two mutating API calls: it deactivates the mapping (the Okta API only allows deleting an INACTIVE mapping, as the provider's own guard message says) and then deletes it. No state was written between them.

If the deactivation succeeds and the delete then fails (for example the transport giving up after repeated 429s in a rate-limited org, or a 5xx), Delete returns error diagnostics without writing state, so Terraform preserves the prior state:

• Reality in Okta: the mapping is INACTIVE and has stopped pushing group membership to the downstream application
• Terraform state and the next plan: status = "ACTIVE"
• What the operator sees: failed to delete push group mapping: ..., identical to the message emitted when the deactivation itself fails, with no indication that group push has stopped

It does self-heal on the next successful apply, but silently, and only if someone re-runs.

Changes

• After a successful deactivation, Delete records status = "INACTIVE" in the response state before attempting the delete
• The two failure modes now have distinct error summaries: failed to deactivate push group mapping before delete and failed to delete push group mapping, and the latter states that the mapping is no longer pushing group membership downstream

State written during Delete is preserved by Terraform when error diagnostics are returned, and discarded when Delete reports no errors, so the write affects only the failure path. In internal/fwserver/server_deleteresource.go (framework v1.18.0) the response state is seeded from prior state, RemoveResource is called only when there are no error diagnostics, and resp.NewState is assigned unconditionally. See the plugin framework Delete documentation.

Testing

• gofmt -l, go build ./..., go vet ./okta/... — clean
• go test ./okta/... (unit, no TF_ACC) — pass
• TestAccResourceOktaPushGroup_crud replayed locally against the existing cassette (OKTA_VCR_TF_ACC=play TF_ACC=1, classic-00) — PASS. It exercises the deactivate-then-delete path, and no new HTTP calls are introduced, so the cassette replays unchanged
• Acceptance tests were not run against a live org; I do not have credentials for one
• A deterministic automated test for the failure window itself isn't practical with the current VCR harness (it would need a hand-crafted cassette where the deactivation succeeds and the delete exhausts transport retries); happy to add one if maintainers can suggest a preferred seam

Notes

• Deliberately scoped to this defect only. fix: handle 404s gracefully in okta_push_group read, update, and delete #2853 and okta_push_group: remove from state on 404 instead of erroring during read #2892 add 404 early returns to Read/Update/Delete of this resource; that is a different failure mode (mapping already gone) and is not duplicated here. The changes are complementary and should merge cleanly in either order, with a small textual conflict at most around the deactivation error return
• No documentation change: the resource schema and behaviour on the success path are unchanged