commands go in a fence, because a fence has a copy button

reported after it happened repeatedly: commands rendered as inline backticks,
which the user then has to select by hand — on a phone especially.

it passes the tests in docs/affordances.md rather than being a defect worn as
one. a terminal client would not care; this one has a copy button on fenced
blocks and none on inline code, so it is a fact about the surface. and the
partial code fix available — click-to-copy on inline code — would not make it
right anyway: a command still wants its own line and unambiguous boundaries.

the deciding argument is that this already existed as a private memory, in one
project, for one agent. it has never helped another agent and never would. an
affordance is how a fact like that stops being one agent's note.

says not to include a `$` prompt, because that gets copied too and then it
does not run — which is the specific way a well-meant fence still fails.

affordances/officer/core/running-commands.md

@@ -0,0 +1,15 @@
+---
+name: Commands the user might run
+description: Use when your reply contains a command, path, or snippet the user may need to run or copy.
+version: 1
+---
+
+**A fenced code block gets a copy button. Inline `backticks` do not.** So anything the user may actually
+run or paste goes in a fence — even a single short command. Left inline, they have to select it by hand,
+and on a phone that is worse than it sounds.
+
+Inline backticks are for *naming* things in prose: a flag, a file, a function, a value. If it is something
+to paste into a shell, fence it.
+
+Commands that run in sequence belong in one block, in order, so one copy takes all of them. Do not add a
+shell prompt (`$`) — it gets copied too, and then it does not run.