OpenFeature: route type mismatch and missing targeting key errors through error hooks #215

Context

Follow-up to #214 (#214).

The new OpenFeature provider surfaces :type_mismatch and :targeting_key_missing as successful resolution tuples containing reason: :error and the appropriate error_code. In open_feature 0.1.3, these run after hooks rather than error hooks. Python and Node throw the corresponding OpenFeature errors, which their SDKs route to error hooks.

Expected behavior

When a flag is read with an incompatible type or no targeting key/default distinct ID is available:

• Return the caller's default with the appropriate OpenFeature error code.
• Invoke registered error hooks, not successful after hooks.
• Preserve finally hook execution.
• Do not route ordinary disabled/unmatched flags through error hooks.

Approach

Coordinate an upstream Elixir OpenFeature SDK change to support these error categories and route them through its error-hook lifecycle while preserving their codes. Then update the PostHog provider and minimum supported dependency version as needed. Simply raising a generic exception is insufficient if it changes the public error code to :general.

Add integration tests using the real OpenFeature client and recording hooks for both error cases and ordinary disabled flags.

This is a follow-up and should not block #214.