feat: pre-work for pending deletion

[lechnerc77]

Purpose

This PR contains the prework for the pending deletion of subaccounts by:

• Introducing the contract_status as a new computed field in the btp_subaccount resource. This field will be needed to discover a pending deletion.
• Switching the deletion logic in the facade to first do a unforced deletion, and if that fails, perform a forced deletion.
• The subaccount deletion could also switch to the UPDATING status, which is also fixed in this PR.

Test fixtures have been re-recorded, so a drift is expected here.

Does this introduce a breaking change?

[ ] Yes
[X] No

Pull Request Type

What kind of change does this Pull Request introduce?

[ ] Bugfix
[X] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

• Test the code via automated test

make test

What to Check

Verify that the following are valid:

• Automated tests are executed successfully

Other Information

See #1331

Checklist for reviewer

The following organizational tasks must be completed before merging this PR:

• The PR status on the Project board is set (typically "in review").
• The PR has the matching labels assigned to it.
• If the PR closes an issue, the issue is referenced.
• Possible follow-up issues are created and linked.

[Copilot]

Pull request overview

This PR implements preparatory work for supporting pending deletion of subaccounts in the SAP BTP Terraform provider. The changes include adding a new contract_status computed field to track the deletion status of subaccounts and inverting the deletion strategy to attempt normal deletion before falling back to forced deletion.

Changes:

• Added contract_status as a new computed field to the btp_subaccount resource and data source to expose the contract status from the API
• Modified the deletion facade logic to first attempt a normal delete (forceDelete=false), then retry with force delete if the error indicates active resources exist
• Added StateUpdating to the list of pending states during subaccount deletion to handle the transitional status correctly

Reviewed changes

Copilot reviewed 16 out of 22 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
internal/btpcli/types/cis/subaccount_response_object.go	Added ContractStatus field to API response type with omitempty JSON tag and manual annotation comment
internal/btpcli/facade_accounts_subaccount.go	Inverted deletion logic: now attempts forceDelete=false first, retries with forceDelete=true if specific error detected
btp/provider/type_subaccount.go	Added ContractStatus field to all subaccount type models and mapping functions
btp/provider/resource_subaccount.go	Added schema definition for contract_status field; added StateUpdating to deletion pending states; includes commented PENDING_FORCED_DELETION handling code
btp/provider/datasource_subaccount.go	Added contract_status schema attribute to data source
btp/provider/datasource_subaccounts.go	Added contract_status to subaccount object type and data source schema; updated mapping logic
btp/provider/resource_subaccount_test.go	Updated all test assertions to verify contract_status = "ACTIVE"
btp/provider/datasource_subaccount_test.go	Added contract_status assertions; updated error message expectation
btp/provider/datasource_subaccounts_test.go	Updated expected subaccount count from 9 to 10 to match re-recorded fixtures
btp/provider/fixtures/*.yaml	Re-recorded test fixtures with new API response fields (contractStatus, lastModifiedBy)