fix(web): keep the plan card to decisions it can actually answer

Review follow-ups on the presentation intent.

The card claimed any single-question request declaring the intent, then sent one
of two labels — so a producer offering a third option, or a multi-select batch,
lost answers the generic flow would have shown. That contradicts the intent's
own contract, so `planReviewOf` now claims only a binary single choice and
leaves everything else to the flow that can express it.

`ask()` also rejects a plan-review intent on a question with no `detail`: the
intent declares detail IS the plan, and without one a honouring UI asks the
user to approve something invisible. The client keeps its own fallback — it sits
downstream of a wire boundary — but the misconfiguration now fails at the asker.

`planReviewOf` stops being a value export of the client contract face (client
export discipline: pure helpers stay internal; the tests already import it
relatively), and the ui-question README fallback list, both languages, now
states every condition the code enforces.

docs/core-data-structures/user-interaction.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write docs/core-data-structures/user-interaction.md
-user-interaction.md: 4ebaf66131b3ab7a7c205bef1ba533e9321d4f0b
-user-interaction.zh.md: 8e5542b995bbf061b097d650ab79505e93151fa8
+user-interaction.md: 2483382eee07d379b13d456149096c8afab70e4b
+user-interaction.zh.md: 57f57277975597fff712705cc741ae8e78643642