fix: handle key recreation when team_id changes or key is cascade deleted

[shin-bot-litellm]

Summary

Related to #12 - Recreate flow reuses deleted resource IDs after team update

Problem

When a team is updated with changes to immutable fields (like team_alias), Terraform destroys and recreates the team. Keys associated with the old team may be cascade deleted in LiteLLM, causing subsequent key updates to fail with:

Error: error updating key: API request failed with status code 401
Response: {"error":{"message":"Authentication Error: invalid user key - user key does not exist in database"...

Solution

1. ForceNew on team_id

Added ForceNew: true to the team_id field in the key resource schema. When team_id changes, the key will be recreated instead of updated, ensuring a clean state.

2. Graceful Missing Key Handling

Added error detection in resourceKeyUpdate that:

• Detects "does not exist" / "not found" / "invalid user key" errors
• Clears the resource ID so Terraform recreates the key
• Returns a warning diagnostic instead of a hard failure

New Behavior

When a team is recreated:

Step	Before	After
Team deleted	Keys orphaned/cascade deleted	Same
Team created	New team ID	Same
Key update	Error: key not found	Key marked for recreation
Key result	Manual intervention needed	Key recreated automatically

Note on Breaking Change

Adding ForceNew: true to team_id means that changing a key's team association will now require key recreation instead of in-place update. This is the safer behavior since:

1. Keys are tightly coupled to teams in LiteLLM
2. Changing team association may invalidate the key
3. Recreation ensures a clean, valid state

[krrishdholakia]

@greptile can you review this?