fix: Enhance Purview scan reliability with collection hierarchy fallback and reparenting logic

[Saswato-Microsoft]

Purpose

This pull request improves the robustness and user guidance for Purview scan automation, particularly around collection hierarchy requirements. The main changes ensure that scans are always created under the correct collection, automatically handling collection reparenting when necessary, and provide clear documentation and error handling for users.

Enhancements to Purview scan automation and documentation:

Automation logic improvements:

• Updated trigger_purview_scan_for_fabric_workspace.ps1 to automatically detect if the deployment collection is not under the datasource's collection and attempt to reparent it as a child, falling back to the datasource's collection if reparenting fails. This prevents Scan_CollectionOutOfBound errors and ensures compliance with Purview's collection hierarchy requirements.

User guidance and documentation:

• Added a note to docs/post_deployment_steps.md explaining that if a tenant-level Fabric datasource already exists under a different collection, the scan script will automatically reparent the deployment collection as needed, and that the deployment collection may appear nested under the datasource's collection in the Purview portal.
• Expanded troubleshooting steps in docs/post_deployment_steps.md to describe the new automatic reparenting behavior for Scan_CollectionOutOfBound errors, and provided instructions for manual intervention if automatic reparenting fails.

Does this introduce a breaking change?

• Yes
• No

Golden Path Validation

• I have tested the primary workflows (the "golden path") to ensure they function correctly without errors.

Deployment Validation

• I have validated the deployment process successfully and all services are running as expected with this change.

What to Check

Verify that the following are valid

• ...

Other Information