DPROD Contracts: DataOffer target and DataContract acceptsOffer cardinality — basket model (5.8 + 5.9)

[jgeluk]

Track: DPROD 1.1 data-contracts post-merge follow-up from PR #156. Stephen's feedback (2026-05-14).

Plan items 5.8 + 5.9 of `dprod-contracts/docs/changes-plan.md`. Coupled — decide together. Stephen's reference-data use case has hundreds of distributions from one provider, of which any subscriber takes a different subset. The 1:1 model (one DataOffer per DataContract) either forces 80+ near-duplicate contracts, or one contract referencing a 100-distribution offer with extra metadata about which 80 obligations apply.

Stephen's proposal:

• 5.8 Tighten `odrl:target` on `dprod:DataOffer` to exactly 1 — each offer is for one distribution
• 5.9 Loosen `dprod:acceptsOffer` on `dprod:DataContract` from `1` to `1..*` — a contract is a basket of accepted offers

Knock-on effects to model:

• Provider duties and consumer duties can be authored as separate offers and composed in the contract, instead of stuffed into one generic provider offer
• Couples to DPROD Contracts: introduce dprod:DataDuty as subtype of odrl:Duty? (5.7) #188 (dprod:DataDuty subtype) — basket-of-offers semantics may need explicit data-duty typing to distinguish provider-duties from consumer-duties across the basket
• Couples to DPROD Contracts: split dprod:State into DutyState and ContractState (1.3 follow-on) #185 (`State` split) — contract lifecycle vs. per-offer-within-contract lifecycle becomes a real distinction

SHACL shape impact: `DataOfferShape` adds `sh:maxCount 1` on `odrl:target`; `DataContractShape` removes `sh:maxCount 1` on `dprod:acceptsOffer`.

Examples to update: `baseline.ttl`, `data-contract.ttl` — show the basket pattern.

cc @tonyseale @matthiasautrata @stevefisher