Proposal: precompute IdentifierHash constants at config-generation time instead of hashing at runtime

[hskang-amelia]

Context

Follow-up idea from #528/#527 (IdentifierHash not stable across compilers). That fix makes the hash algorithm itself portable (FNV-1a), but every ControlClient and Launch Manager still independently compute IdentifierHash(name) at runtime and trust that their implementations agree — which is exactly the assumption that broke there.

Proposal (exploratory — not asking for this to be merged as-is)

Every component/run target name is already known once, at config-generation time (scripts/config_mapping/lifecycle_config.py). This proof of concept computes each name's FNV-1a hash there too, and emits it as a generated Rust module of constants (new --emit-rust-hashes flag), instead of leaving every consumer to hash the same string again at runtime.

Working branch (not a PR yet, deliberately — wanted to verify it actually works before proposing): https://github.com/hskang-amelia/lifecycle/tree/poc/config-driven-hash-codegen

Verified: added a test asserting the real C++ IdentifierHash("state_manager").data() / IdentifierHash("Startup").data() equal the exact values this Python generator independently produced for the same names — byte-identical, no shared code path between the two computations beyond both implementing FNV-1a. bazel test //score/launch_manager/src/daemon/src/common:identifier_hash_UT and the existing //scripts/config_mapping/tests:lifecycle_config_tests both still pass.

What this doesn't do (yet)

Doesn't change ControlClient::ActivateRunTarget()'s API (still takes a string, still hashes at runtime internally) or any Launch Manager runtime behavior — it only proves the values are derivable ahead of time and stay consistent. Making that actually load-bearing (e.g. an ActivateRunTarget overload that accepts a precomputed hash directly, bypassing runtime hashing entirely) would be a separate, larger API change I haven't attempted here.

Ask

Is this a direction worth pursuing further (and if so, as a proper Improvement PR per CONTRIBUTION.md), or is there a reason this shouldn't happen — e.g. hash collision handling, multi-language consumers beyond Rust/C++, or a preference for keeping ControlClient's API string-only? Happy to take feedback before investing in the larger API-surface version.

[hskang-amelia]

Closing this — found that it's moot. #478/#489 (new mw::com-based control API) define RunTargetName as FixedString<128>, sent directly over mw::com — no IdentifierHash/runtime string-hashing involved at all in the new design. Once that lands, this whole class of problem (and this proposal) goes away on its own, since there's nothing left to precompute.

Leaving #527/#528 open since the old ControlClientChannel path is still the active one until #489 merges — that's a real, reproducible crash in currently-used code, unrelated to this specific proposal.