fix(api): use store subgraphs for entity summary reads

[jonathanhaaswriter]

Summary

• add a graph-intelligence service path that serves entity summary requests from bounded store subgraphs for current reads
• fall back to full graph views only for historical requests unless the backing store supports bitemporal subgraph extraction
• cover the entity summary handler with service-backed and store-backed tests, including live-graph preference over snapshot materialization

Testing

• go test ./internal/api -run 'TestGraphIntelligenceEntitySummaryUsesServiceInterface|TestPlatformEntitySummaryUsesStoreSubgraphWhenSnapshotsUnavailable|TestPlatformEntitySummaryPrefersLiveGraphOverSnapshotWhenAvailable|TestPlatformEntityHandlersUseGraphStoreWhenRawGraphUnavailable|TestPlatformEntitySummaryReport'
• python3 ./scripts/devex.py run --mode changed --base-ref writer/main

[jonathanhaaswriter]

One blocking concern from this pass:

• internal/api/server_services_graph_intelligence.go:CurrentEntityGraph now builds summaries from a 3-hop extracted subgraph, but BuildEntitySummaryReport includes facets that are not edge-local. For example, evaluation-quality reads target_ids metadata and workload-security asks for CascadingBlastRadius(..., 4), so the summary can silently under-report data.

Can we keep the full graph here, or make the extraction strategy facet-aware instead of using one fixed depth?

[jonathanhaaswriter]

I think temporal entity-summary requests can still fail on store-backed runtimes without snapshot support. When valid_at / recorded_at is set and the store doesn't implement bitemporal subgraph extraction, the fallback path still goes through currentOrStoredGraphView() -> store.Snapshot(). That means the same no-snapshot store-backed setup this PR is trying to fix can still 503 for temporal reads.

Can we fall back to plain ExtractSubgraph(...) (or plumb bitemporal extraction through the tiered store) instead of requiring snapshots here?