docs(sdk): fige le contrat command-and-feedback et aligne l'exemple hello-plugin

Documente la règle publique menu -> command handler -> tâche de fond optionnelle
-> feedback (docs/commands-and-feedback.md + README), clarifie via JSDoc les
invariants de runCommand/recordOnly/ownerAgentId dans runtime.ts, et met à jour
l'exemple hello-plugin (feedback structuré launched/skipped, watch non-fatal)
pour qu'il illustre fidèlement le contrat documenté. Publie docs/ dans le
package npm.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

README.md

@@ -17,6 +17,40 @@ This first version intentionally stays small:
 - a lightweight manifest validator;
 - a minimal `examples/hello-plugin` plugin.
 
+## Command And Feedback Contract
+
+Plugin menu actions follow one public contract:
+
+```text
+menu click -> registered command handler -> optional background task -> feedback surfaces
+```
+
+A menu item only names a command. The registered command handler owns all
+precondition checks, task launch decisions and feedback. If a command
+cannot or should not start work, return a small structured result such as
+`{ status: "skipped", reason, message }` and log the same reason. That return
+value is useful for programmatic callers, agents and future host surfaces; the
+current human menu-click UI does not guarantee that handler return values are
+shown to the user. Do not create a background task just to represent a skipped
+command.
+
+Use `ctx.services.tasks.runCommand()` only after required preconditions are
+true: a focused project exists, the plugin has the `tooling` capability, required
+executables/files/env are present, and a real `ownerAgentId` is available when
+the result belongs to an agent workflow. `ownerAgentId` controls Work ownership,
+cancellation and completion delivery; it must not be a placeholder in production
+plugin code.
+
+`recordOnly: true` records completion without waking the owner agent. It is not a
+silent mode and it does not hide the task from surfaces that show Work state or
+background-task events. If no task is launched, the baseline feedback surfaces
+are the command result for programmatic callers and plugin logs; human-visible UI
+feedback requires a host-supported surface, a real background task, or a
+plugin-owned UI/file surface.
+
+Canonical rules and examples live in
+[`docs/commands-and-feedback.md`](docs/commands-and-feedback.md).
+
 ## Install
 
 ```sh
@@ -236,8 +270,10 @@ export async function activate(ctx: ActivateContext): Promise<void> {
 ```
 
 `watch(path, handler, projectId?)` subscribes to public workspace file-change
-events for the given relative path. It is best-effort and bounded: plugins should
-handle missed events by refreshing their own derived state when needed.
+events for the given relative path. It is best-effort and bounded: hosts may
+reject it until workspace watching is implemented, and plugins must treat setup
+failure as non-fatal. Plugins should also handle missed events by refreshing
+their own derived state when needed.
 
 ### Project Structure