memory_utils: `build_memory_config` requires `ES_HOST` to include a port — most ES URLs don't

backend/utils/memory_utils.py:25-31:

if not _c.ES_HOST:
    raise ValueError("ES_HOST is not configured")
parsed = urlparse(_c.ES_HOST)
if not (parsed.scheme and parsed.hostname and parsed.port):
    raise ValueError("ES_HOST must include scheme, host and port, e.g. http://host:9200")
es_host = f"{parsed.scheme}://{parsed.hostname}"
es_port = parsed.port

The check rejects perfectly valid Elasticsearch URLs like:

• https://search.example.com (HTTPS default port)
• http://elasticsearch (Docker Compose service name, port 9200 implied)
• https://my-deployment-abc.es.us-east-1.aws.elastic-cloud.com (Elastic Cloud — no port)

For Elastic Cloud in particular, the deployment URL never has a port. Operators using the managed offering have to invent :443 to get past this validator, which is needless ceremony.

Suggested fix

Apply scheme defaults:

parsed = urlparse(_c.ES_HOST)
if not (parsed.scheme and parsed.hostname):
    raise ValueError("ES_HOST must include scheme and host, e.g. https://my-es:9200")
default_port = {"http": 9200, "https": 443}.get(parsed.scheme, 9200)
es_port = parsed.port or default_port

Also note line 68 sets "verify_certs": False unconditionally for the mem0 vector store config. For a managed Elastic Cloud deployment that's an awful default — silently disables cert pinning. This should follow the same flag as the rest of the codebase (see sdk/nexent/vector_database/elasticsearch_core.py:52 which exposes verify_certs as a constructor parameter).

Category: D (config bug). Severity: Medium.

Start in backend/utils/memory_utils.py:25-31 and inspect how build_memory_config parses ES_HOST and how line 68 sets verify_certs. Compare the expected certificate behavior with sdk/nexent/vector_database/elasticsearch_core.py:52. Done means valid HTTP and HTTPS hosts work without an explicit port, invalid hosts still fail clearly, and certificate verification follows the existing configuration approach.