[BUG] Inconsistent error behavior between Resolve<T> and ResolveAll during flagd runtime

Observed behavior

For targeting rules that can return different types based on the context (which does not conform to schema but is allowed by flagd with just a warning):

• ResolveAll checks whether the type of the evaluated variant matches the type of the defaultVariant
• Resolve<T> checks whether the type of the evaluated variant matches <T> (defaultVariant does not matter)

Expected Behavior

I would expect the behavior to be consistent. If defaultVariant is used to infer the flag type, then Resolve<T> methods should also check whether <T> matches the type of defaultVariant and not the type of the evaluated variant.

Steps to reproduce

For the following flag config:

{
    "$schema": "https://flagd.dev/schema/v0/flags.json",
    "flags": {
      "is-enabled": {
        "defaultVariant": "off",
        "state": "ENABLED",
        "targeting": {
          "if": [
            {
              "<": [
                {
                  "%": [
                    {
                      "var": "request_id"
                    },
                    1000
                  ]
                },
                100
              ]
            },
            "on",
            "off"
          ]
        },
        "variants": {
          "on": 1,
          "off": false
        }
      }
    }
  }

flagd returns the following:

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveBoolean" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 42}}' -H "Content-Type: application/json"
{"code":"invalid_argument","message":"Type mismatch error"}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveBoolean" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 420}}' -H "Content-Type: application/json"
{"value":false, "reason":"TARGETING_MATCH", "variant":"off", "metadata":{}}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveInt" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 42}}' -H "Content-Type: application/json"
{"value":"1", "reason":"TARGETING_MATCH", "variant":"on", "metadata":{}}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveInt" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 420}}' -H "Content-Type: application/json"
{"code":"invalid_argument","message":"Type mismatch error"}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveAll" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 42}}' -H "Content-Type: application/json"
{"flags":{"is-enabled":{"reason":"ERROR", "variant":"on", "boolValue":false}}}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveAll" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 420}}' -H "Content-Type: application/json"
{"flags":{"is-enabled":{"reason":"TARGETING_MATCH", "variant":"off", "boolValue":false}}}%

When changing the defaultVariant in the config:

{
    "$schema": "https://flagd.dev/schema/v0/flags.json",
    "flags": {
      "is-enabled": {
        "defaultVariant": "on",
...
      }
    }
  }

ResolveAll responses:

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveAll" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 42}}' -H "Content-Type: application/json"
{"flags":{"is-enabled":{"reason":"TARGETING_MATCH", "variant":"on", "doubleValue":1}}}%

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveAll" \
  -d '{"flagKey":"is-enabled","context":{"request_id": 420}}' -H "Content-Type: application/json"
{"flags":{"is-enabled":{"reason":"ERROR", "variant":"off", "doubleValue":0}}}%

Start by locating the Go implementations or handlers for Resolve and ResolveAll, then reproduce the supplied flag configuration and requests with both defaultVariant values. Compare how each path infers and validates the flag type. Done means both APIs apply consistent type-checking behavior for the same configuration and the reproduction cases are covered by tests.