Specify ontology regression cases that expect no property binding

[virtue039]

A regression case currently requires an expected property, so a person cannot record that an open statement should bind to nothing. This documentation-only change adds that contract to decision 0061 before any migration, API or UI implementation.

Existing positive requests remain compatible. An explicit expected_binding: "none" carries no property or direction; both stored target fields are null, with same-base isolation and idempotent confirmation preserved. Only an explicit none decision passes a negative case: bound and undecided fail, while no decision remains unchecked.

The human-bound exception applies only to positive cases. A negative case that conflicts with a person's binding must fail and explicitly report the conflict and actual binding; the case does not overwrite the person's decision. This addresses the review of October 14. The proposed section is reduced from 78 to 41 lines and keeps the four contract decisions; index, UI and acceptance details are deferred to the implementation PR.

Validation: inspected the request examples and comparison rules for consistency; git diff --check passes at f976bda (macOS). One ADR changes, with no runtime or migration changes, so runtime/model suites were not rerun. The overall ADR remains In progress, this section remains proposed, and implementation waits for contract merge.

Refs #1103, #1184.

[WaylandYang]

Thank you for writing the contract down before building it; negative cases are the gap #1103 left open, and the shape reads right.

On your question: please do not extend the human-bound exception to negative cases. When a person bound the signature and another person says this statement should bind to nothing, the two human decisions disagree; the case should fail and say so (a conflict with the human binding), not pass. Hiding that is exactly what a negative case is meant to catch.

One request: keep the ADR to the decisions (the request shape, nullable target, the comparison rules, this exception). The acceptance checklist and implementation detail can go into the implementation PR's description.

Thanks again.