test(destination): enable multi-tenant BDD scenarios

[ArthurTonial]

Disclaimer: Do not include SAP-internal or customer-specific information in this PR (e.g. internal system URLs, customer names, tenant IDs, or confidential configurations). This is a public repository.

Description

Implements and fixes multi-tenant integration test scenarios for the Destination, Fragment, and Certificate modules, completing the acceptance criteria of the business need.

What changed:

• Enabled multi-tenant BDD scenarios (destination, fragment, certificate): uncommented and rewrote previously commented-out scenarios that were hardcoded to a specific tenant ID. All subscriber-context scenarios now use CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN via the new Given I use the configured subscriber tenant step. Scenarios are automatically skipped when the variable is not set.
• Added @given("I use the configured subscriber tenant") step: reads CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN from the environment, following the CLOUD_SDK_CFG_<MODULE>_DEFAULT_* naming convention used across all modules.
• Added end-to-end subscriber write scenarios for destinations, fragments, and certificates: create → update → delete → isolation check at subaccount level with subscriber tenant context.
• Fixed 7 failing integration tests:
  • Six PROVIDER_FIRST list scenarios were missing the subscriber tenant step, causing DestinationOperationError at runtime.
  • The "list instance destinations with tenant" scenario was creating destinations in the provider scope and asserting they appeared in the subscriber scope (different namespaces). Simplified to assert the list call succeeds.
• Reorganized docs and env example: alphabetically sorted docs/INTEGRATION_TESTS.md sections and .env_integration_tests.example entries; added CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN documentation under the Destination section.

Related Issue

Closes #

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Dependency update

How to Test

1. Copy .env_integration_tests.example to .env_integration_tests and fill in the destination service credentials.
2. Set CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN to a subscriber tenant subdomain that has access to the destination service instance.
3. Run the integration tests:

   uv run pytest tests/destination/integration/ -v

4. Subscriber scenarios (create/update/delete/isolation) should execute and pass. Without CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN, those scenarios are skipped and all provider-only scenarios should pass.

Checklist

• I have read the Contributing Guidelines
• I have verified that my changes solve the issue
• I have added/updated automated tests to cover my changes
• All tests pass locally
• I have verified that my code follows the Code Guidelines
• I have updated documentation (if applicable)
• I have added type hints for all public APIs
• My code does not contain sensitive information (credentials, tokens, etc.)
• I have followed Conventional Commits for commit messages

Additional Notes

CLOUD_SDK_CFG_DESTINATION_DEFAULT_TENANT_SUBDOMAIN follows the same naming convention as other modules (e.g. CLOUD_SDK_CFG_AGW_DEFAULT_TENANT_SUBDOMAIN). Scenarios requiring it are automatically skipped when absent, so the test suite remains fully runnable in provider-only environments.