topology-background-service silently returns None: cim-graph 0.5.0a9 exceeds unenforced <0.5.0 cap

[craigpnnl]

Symptom

topology-background-service connects to Blazegraph but get_object() on a known-good ieee123 feeder mRID silently returns None instead of a cim.Feeder. Reproduced live against Blazegraph inside the running gridappsd container:

Instantiated BlazegraphConnection OK
get_object(mRID="c1c3e687-6ffd-c753-582b-632a27e28507") returned: <class 'NoneType'>

No exception is raised; the service just yields nothing for a feeder that exists in the store.

Root cause

services/gridappsd-topology-background-service/pyproject.toml:39 pins:

cim-graph = ">=0.4.3a6,<0.5.0"

but the image ships cim-graph 0.5.0a9, above that cap. The cap is never enforced: this service ships only a Poetry pyproject.toml and no requirements.txt, while entrypoint.sh:452 installs only services/*/requirements.txt. With no matching requirements.txt, the service constraint is never applied, so the platform's unpinned root requirements.txt float (gridappsd-python -> gridappsd-field-bus -> cim-graph>=0.4.3a6) wins and drags in 0.5.0a9. The 0.5.x connection/query surface differs enough that get_object returns None where 0.4.3a12 would resolve the feeder.

This is NOT a version drift between images

:local, :develop, and :feat_topology-success-logging all bake identical cim-graph 0.5.0a9 (verified via pip show cim-graph in each image). There is no build-to-build cim-graph difference; do not chase a phantom image delta. The break is the single unenforced cap above.

This is NOT the Java bnd axis

The goss-core 16.0.x version referenced in PR #1900 comments is a separate (Java bnd run.bnd.bndrun) dependency graph and is unrelated to this Python break. Do not conflate the two.

Proposed fix

Either:

1. Pin cim-graph<0.5.0 (or ==0.4.3a12) in the platform root requirements.txt, OR
2. Ship topology-processor's constraint as a real services/gridappsd-topology-background-service/requirements.txt so entrypoint.sh actually applies its cap.

Option 1 fixes it platform-wide; option 2 makes the service self-describing. Note gridappsd-python itself declares no cim dependency, so no change is needed there.