fix(ccr0316): correct $send-message return type and document preconditions

[jhntrifork]

Summary

Follow-up to the original CCR0316 IG work (commit e407e68d) and downstream fut-patient PR #3334.

The return parameter on Appointment-send-message was declared as type: Reference with targetProfile: ehealth-message. The operation actually returns the created Communication resource embedded in a Parameters response — both per CCR0316 §6 (OUT return ... type Communication) and per the fut-patient implementation (SendMessageOperationHandler → Parameters with result.getParameterFirstRep().getResource() returning a Communication). A strict consumer or code generator that trusts the OperationDefinition would expect a Reference and break.

This PR corrects the contract and fills out the documentation that was previously sparse.

Changes

• Return parameter: type → Communication, drop targetProfile, rewrite documentation to point at the ehealth-message profile and document the completed/stopped status semantics.
• New comment field listing the preconditions that yield HTTP 400 Bad Request — appointment profile (video/group-video) and status (booked/pending), participant status (accepted/tentative/needs-action), RelatedPerson active/period/telecom:video-appointment-reminder-sms — and a note on the persist-on-failure audit behaviour.
• Cross-links in description to the ehealth-relatedperson, ehealth-appointment and ehealth-message profile pages.
• Changelog entry for release_2026.3 updated to reflect the corrected return type and the documented preconditions.

Downstream impact

No code changes required in fut-patient — the implementation already matches the corrected contract. Consumers that hand-rolled their own client from the previous (Reference-typed) OperationDefinition will need to update once they pick up this release.