fix(security): apply the connector SSRF guard to the DataStax Data API endpoint (#14636)

* fix(security): apply the connector SSRF guard to the DataStax Data API endpoint

The DataStax Astra DB / HCD components resolved a tenant-controlled API endpoint
and handed it straight to the astrapy client together with the configured
application token, without passing through `validate_connector_url_for_ssrf`.
Every sibling connector already applies that guard -- including `astradb_cql`
in the same bundle -- so the Data API path was the only hole in a default-on
policy, and a flow author could aim it at an internal or cloud-metadata host.

Route the endpoint through the shared guard at the resolution boundary in
`AstraDBBaseComponent` so every component built on it inherits the check:

- `validate_api_endpoint()` helper wrapping `validate_connector_url_for_ssrf`,
  a no-op for an unset endpoint so build_config paths keep working.
- `get_api_endpoint_static()` validates both tenant-controlled forms: the
  explicit `api_endpoint` field and a `https://`-prefixed `database_name`.
- `get_database_object()`, `collection_data()`, `get_vectorize_providers()` and
  both `create_collection_api()` implementations validate the endpoint before
  building a client, and outside the blanket handlers that would otherwise
  swallow or remap the error.
- `HCDVectorStoreComponent.build_vector_store()` validates its endpoint too.

Operators who legitimately point Astra/HCD at a private network keep the
documented escape hatches (LANGFLOW_SSRF_ALLOWED_HOSTS, or
LANGFLOW_CONNECTOR_SSRF_VALIDATION_ENABLED=false).

Adds `tests/test_astradb_connector_ssrf.py` covering each entry point: the
guard must raise before any client is constructed, and the allowlist must still
let a configured endpoint through. Existing offline tests that use
non-resolvable placeholder endpoints now allowlist them via a shared fixture
rather than disabling the guard.

Fixes LE-2243

* chore(bundles): bump lfx-datastax to 0.1.4 and realign the release contracts

The release-plan guard requires a version bump whenever releasable bundle source
changes, and this PR modifies src/bundles/datastax. Generated by
bundle_release_plan.py update, with the enterprise-hardened profile lock
regenerated via manage_bundle_profiles.py compile so the checked-in contracts
match the new pyproject floor.

* test(datastax): track the manifest version instead of hardcoding it

The lfx-datastax bump this PR needs broke test_manifest_exposes_cassandra_as_a_separate_bundle,
which asserted manifest["version"] == "0.1.3". The release-plan guard bumps the
bundle whenever releasable source changes, so a literal here turns every such bump
into a spurious failure while checking nothing real.

Assert the manifest matches the installed distribution instead. That keeps the
invariant worth having -- extension.json and pyproject moving in lockstep, where
bumping one without the other is the actual bug -- and matches what the toolguard
bundle already does. Verified it still fails when the two diverge.