[AAP-75240] Fix role_team_assignment content_type mismatch causing 4…

[rohitthakur2590]

…00/500 errors and enable resource-level type support

Description

• What is being changed?
  Three changes in plugins/modules/role_team_assignment.py:

Replaced the hardcoded allowed type list in _validate_selector() , the old code only permitted type: organizations and type: teams in assignment_objects. It now accepts all resource-level types (projects, inventories, credentials, job_templates, activations, event_streams, decision_environments, and all Hub/Galaxy types) by deriving the allowed set dynamically from a new CONTENT_TYPE_ENDPOINT_MAP constant.
Added type-match validation , when a user provides type: in assignment_objects, the module now validates that it matches what the role definition's content_type actually expects. A mismatch produces a clear, actionable error message instead of a cryptic 400/500 from the Gateway API.
Changed the gate in main() from elif entity_type and object_param: to elif object_param: the block now runs whenever assignment_objects is provided, regardless of whether the role has a content_type. This also correctly handles the object_id and object_ansible_id paths within the loop.

• Why is this change needed?
  The bug was introduced in v2.6.20260306 when the entity_type derivation changed from prefix-matching on the role name to reading content_type directly from the API response. This was architecturally correct but exposed two pre-existing problems:

Bug 1 (400/500): A role like "Launch User Role - Projects" has content_type = "awx.project". When combined with type: organizations in assignment_objects, the module correctly looked up the organization (id=42) but then sent that org ID as object_id for a role the Gateway API expects to point at a project. The API rejected it with 400 "Project matching query does not exist." or 500 Internal Server Error. Before v2.6.20260306 this was a silent no-op (nothing was assigned) because the old prefix-matching code set entity_type = None for non-"Team"/"Organization" role names, skipping the block entirely.
Bug 2 (blocked type): Even users who correctly knew they needed type: projects for a project-scoped role could not use it — the hardcoded allowed = ("organizations", "teams") rejected it immediately with "Unsupported type 'projects'". This made it impossible to assign any resource-level role by name without falling back to ansible.builtin.uri directly.

• How does this change address the issue?
  The fix validates the type combination before any API call is made

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Test update
• Refactoring (no functional changes)
• Development environment change
• Configuration change

Self-Review Checklist

• I have performed a self-review of my code
• I have added relevant comments to complex code sections
• I have updated documentation where needed
• I have considered the security impact of these changes
• I have considered performance implications
• I have thought about error handling and edge cases
• I have tested the changes in my local environment

Testing Instructions

Prerequisites

Steps to Test

Expected Results

Additional Context

Required Actions

• Requires documentation updates
• Requires downstream repository changes
• Requires infrastructure/deployment changes
• Requires coordination with other teams
• Blocked by PR/MR: #XXX

Screenshots/Logs

[github-actions]

DVCS PR Check Results:

PR appears valid (JIRA key(s) found)