DPROD Contracts: reject duty-only properties on non-Duty rules

[jgeluk]

Context

Follow-up from #198 (fixme.md item 22), related to #184.

dprod:deadline, dprod:recurrence, dprod:subjectOfDuty, and dprod:objectOfDuty are duty-only properties. Their OWL domains describe that intent but do not validate input. A Permission or Prohibition carrying one of these properties is not explicitly rejected by the current SHACL graph; reasoning can instead infer an unintended additional odrl:Duty type.

That is not fail-fast validation and can produce resources belonging to ODRL-disjoint rule classes.

Acceptance criteria

1. Add regression tests first for each duty-only property used on an odrl:Permission and an odrl:Prohibition; each case must currently demonstrate the validation gap.
2. Add SHACL violations targeting non-Duty subjects of the duty-only properties.
3. Keep valid named and inline Duty instances conformant.
4. Cover the schedule/recurrence model produced by DPROD Contracts: Bucket 4 — recurrence redesign #184 rather than preserving obsolete string-RRULE assumptions.
5. Document the class scope of each property in the specification and usage matrix.

[jgeluk]

Implementation scope after the agreed #184 Schedule redesign:

• dprod:deadline, dprod:subjectOfDuty, and dprod:objectOfDuty remain duty-only and will fail SHACL validation on every non-odrl:Duty subject.
• dprod:recurrence is obsolete under DPROD Contracts: Bucket 4 — recurrence redesign #184 and already fails validation everywhere; it will not be retained as a duty-only RRULE property.
• dprod:schedule is intentionally not duty-only. The DPROD Contracts: Bucket 4 — recurrence redesign #184 decision defines it as a generic reference from duties, permissions, maintenance arrangements, backup obligations, and other resources. Restricting it to Duty here would contradict that model.

The regression coverage will therefore test Permission and Prohibition misuse of the three surviving duty-only properties, global rejection of obsolete dprod:recurrence, valid named and inline duties, and valid generic schedule use. Because #184 is still draft PR #234, the #239 implementation will be stacked on that branch rather than encoding the obsolete model on develop.