v0.5.434-rete-plus-develop: fix stale xid->uid negative cache poisoning processing CO2 Builds on v0.5.433 with one targeted correctness fix: - 7f90ba18d fix(processing): re-resolve stale xid->uid mappings poisoned by negative cache Root cause: the process-lifetime find_uid_by_xid cache (introduced in 36348c871) cached negative lookups, but bulk_insert_xid_uid_mappings never invalidated them. The processing-seed path looked up every process xid before the Brightway rows existed -> cached None -> later inserts wrote the real rows but left the negative cache in place. The GFM kept loading ProcessingTagsAndId with uid=None, making load_brightway_node_and_subgraph bail out and silently dropping the processing CO2 contribution. Fix has two complementary parts: - pg_product_mgr.bulk_insert/bulk_delete_xid_uid_mappings now update the cache for affected keys instead of leaving stale entries. - processing_gfm.init_cache re-resolves trigger.uid from the stable xid when the cached uid is None, so a stale gfm_cache self-corrects on next init. Validation: - test_processing_gfm.py: 7 failed / 2 passed -> 9 passed - core gauntlet: 417 passed / 1 pre-existing failure (kWh self-reference unit conversion, unrelated to this change) Expected cluster effect: the per-recipe "1-2% lower CO2 than develop" on combined recipes should close to zero on any recipe that triggers a processing step. Cluster benchmark variance (2-4x noise on identical builds) still applies — verify with median over multiple runs, not a single-shot comparison. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>