The new audit log silently omits removed feature states. `get_updated_feature_states_for_version()` only iterates the **new** version's feature states and compares them against the previous version — it never walks the previous version looking for keys that don't appear in the new one. So when a user publishes a version whose only change is dropping a segment override (e.g. via `segment_ids_to_delete_overrides`), the removed override is never visited and the audit log falls back to just the head

The audit-log summary only reports each changed feature state's scope and current `enabled`/`disabled` flag, but `get_updated_feature_states_for_version` also flags states whose `feature_state_value` or multivariate values changed while `enabled` stayed the same. Such value-only edits produce a line indistinguishable from an enabled-toggle change (e.g. `- Environment default: enabled`), defeating this PR's stated goal of making EFV audit logs less opaque. Consider including the value/MV diff (or