Validate that a VM patch applies to an obfuscated release (base ↔ patch obfuscation parity)

[kennedyowusu]

Summary

koolbase release forwards --obfuscate to the per-ABI builds, so an obfuscated base binary can be produced. What hasn't been validated is whether a VM patch applies on-device to an obfuscated base — and what obfuscation settings a patch must be built with to match that base.

This is orthogonal to #1 (which covers --split-debug-info symbol maps being lost to the inter-ABI flutter clean, a crash-symbolication bug). This issue is about code push applying to obfuscated binaries, not about symbol maps.

Background

• --obfuscate reaches the inner per-ABI builds as passthrough, so each ABI's AOT snapshot is compiled obfuscated.
• Obfuscation renames symbols and alters the compiled snapshot. A VM patch is a diff against that snapshot, so the patch's view of the base must match the obfuscated base exactly.

Open questions

1. Does a patch built against an obfuscated base apply cleanly on-device?
2. Must the patch be built with the same obfuscation settings as the base (expected: yes)? What happens if they differ — clean failure, or silent misapply?
3. Is obfuscation deterministic enough across builds that a separately-built patch resolves the same symbols as the shipped base, or does the patch workflow need the base build's artifacts/seed to stay in sync?

Acceptance criteria

• Build an obfuscated release:
  koolbase release android --flavor <flavor> -- --obfuscate --split-debug-info=<dir outside build/>
• Build a patch against that base with matching obfuscation settings, push it, and confirm it applies on a physical device.
• Document the base↔patch obfuscation-parity requirement in the patch docs.
• If parity can't be guaranteed across independent builds, document the required workflow (e.g. retaining base artifacts) or gate/​warn in the CLI.

Notes

• Depends on release: --split-debug-info under build/ is wiped by inter-ABI flutter clean (obfuscated releases silently lose arm64 symbols) #1 being resolved for a clean obfuscated release (so symbol maps aren't lost), but the patch-apply question is independent and stands on its own.
• Until validated, obfuscation should be documented as "forwarded via passthrough; patch-apply not yet validated" rather than fully supported.

Related: #1