Conformance suite batch default-value module tests sub-field merging, which c-3-2-7 and #231 rule out

Running the AuthZEN plans from the OIDF conformance suite against a PDP surfaces a conflict between the harness and the certification scenario on batch default values.

certification/authorization-api-1_0-scenario.md c-3-2-7 states the semantics as whole-object replacement:

An evaluation that omits one of these keys inherits the entire top-level value; an evaluation that provides a key overrides the top-level default at the entity level (whole-object replacement). ... There is no sub-field merging: a per-evaluation entity either is complete or is absent (inherited whole).

The conformance suite module authzen-pdp-evaluations-batch-with-default-value-merging (src/main/java/net/openid/conformance/authzen/scenarios/evaluations/AuthzenPDPEvaluationsBatchWithDefaultValueMergingTest.java) sends:

{
  "subject": { "type": "user", "id": "alice" },
  "action": { "name": "write" },
  "resource": { "type": "record" },
  "evaluations": [
    { "resource": { "id": "record-1", "properties": { "status": "active" } } },
    { "resource": { "type": "record", "id": "record-2", "properties": { "status": "archived" } } }
  ]
}

and expects [true, false]. The first evaluation provides resource but omits resource.type, so returning true requires inheriting type from the top-level default. That is sub-field merging, which c-3-2-7 rules out.

This was settled in #231. PR #233 adopted Option A from that issue, which is whole-value replacement, and that is the text 7.1.1 still descends from:

If any of the top-level subject, action, resource, and context keys are provided, the value of the top-level key is treated as the default value for the 4-tuples specified in the evaluations array. If a top-level key is specified in the 4-tuples present in the evaluations array then the value of that will take precedence over these default values.

Option B in #231 was the sub-field merging alternative and was not adopted. The current 7.1.1 sentence "Because subject, action, and resource are required for a valid evaluation, any of these keys omitted from an evaluation object MUST be provided as a top-level key" points the same way: it only has force if a provided entity must be complete.

So a PDP that implements 7.1.1 and c-3-2-7 fails this harness module, and a PDP that passes it contradicts both. The module's first evaluation should either carry a complete resource or omit the key entirely.

The same module appears in authzen-pdp-evaluations-test-plan and authzen-pdp-evaluations-comprehensive-test-plan.

Start with src/main/java/net/openid/conformance/authzen/scenarios/evaluations/AuthzenPDPEvaluationsBatchWithDefaultValueMergingTest.java and compare its first evaluation with c-3-2-7 in certification/authorization-api-1_0-scenario.md and the decision in #231. Check the corresponding authzen-pdp-evaluations-test-plan and authzen-pdp-evaluations-comprehensive-test-plan modules, then run the batch scenario; done means the fixture and expected results consistently test whole-value replacement.