fix: align CLI override & config plugin flag resolution

[sterlingwes]

Why

The CLI and the config plugin each reassembled flag resolution by hand, consuming different subsets of the inputs (defaults, branch, env, invertFor, platform). Two problems fell out of that:

1. CLI and plugin disagreed and clobbered each other — both write mergePath with different logic, so re-running one undid the other. --skip-if-env only existed to paper over this in EAS.
2. invertFor.bundleId was unreliable under dynamic Expo config — inversion keys off the resolved bundle ID, which the plugin sees at prebuild but the CLI never did (it never resolved the Expo config).

What changed

• One resolver (src/api/resolve.ts) is the only place flag values are computed — precedence: defaults → branch → inversion → enable → disable. CLI, plugin native side-effects, JS bundle module, and autolinking all route through it. Removed the duplicated generateOverrides, the standalone resolveFlagsToInvert, and the BuildFlags class.
• CLI and plugin now produce identical output for the same context, so re-running is a no-op; --skip-if-env is demoted to an optional optimization. An agreement test guards this.
• CLI resolves the Expo config via expo config --json (lazily, only when a bundleId matcher exists, and cached), so it sees the same dynamically-derived bundle ID as the plugin.
• New invertFor.platform matcher + per-platform output — flags can resolve differently per platform; the runtime module splits into .ios.ts/.android.ts only when values diverge (otherwise single module, with stale-file cleanup). The babel plugin picks the right file per compile platform.
• Autolinking exclusions derive from the resolved per-platform FlagMap, removing the old "enable-list only" caveat.

Compatibility

Pre-1.0, breaking by design. override/ota-override and EXPO_BUILD_FLAGS are unchanged; flags.yml gains invertFor.platform. Existing invertFor.bundleId specs get more reliable behavior with no changes.

Closes #11