Set or clear this account's operator instructions

Body for the three owner-only operator-instruction writes.

ONE MODEL FOR ACCOUNT, SITE AND CAMERA. The field, the cap, the trim rule and the null semantics are identical at all three levels by decision, and ops-view mirrors them in one editor component — see the package docstring for why this lives under shared/ rather than in three copies.

ABSOLUTE WRITE, NO PATCH SEMANTIC. Omitting the field is identical to sending null and means CLEAR, matching how agent_context is written.

NO examples= ON THE FIELD, DELIBERATELY. Real instruction text is after-hours phone numbers and premise procedure; an example in the published OpenAPI would be a plausible-looking one sitting in every generated client and doc page, and "sample" premise procedure is exactly the sort of thing that gets pasted in and acted on. The description carries the contract instead.

The three operator-instruction writes answer the written value, nothing else.

MINIMAL BY DECISION (Round-0 ruling Q4), and a visible divergence from the PUT /sites/{id}/agent-config route these are modelled on — that one returns the full EditSiteResponse. Doing the same here would force operator_instructions into three large response models and, for sites, into Sites.to_dict_complete(): the serializer that feeds both SSE broadcast builders, the operator queue, history and GET /events/{id}. The whole design rests on that serializer never learning the field, so the response shape follows from it rather than the other way round.

The service layer returns the resource's display name alongside these two keys — the router needs it for the activity-log summary — and pydantic drops it here (extra="ignore"). That is deliberate, not an oversight, and is pinned by a router test asserting the body carries exactly these two keys: the name is audit material, not part of this contract.