docs(agent): let check's own output decide the 0.12.0 ledger's v2 steps

Instead of preconditions on login state, run check --json once after init and
act on the messages it prints: a copy of an issued rule, an edited rule, a
pre-v2 runtime rule, a missing rule. A run where signatures do not apply
(logged out, an expired token, an uncovered repository) prints none of them,
so there is nothing to decide up front.

Author: theCodeDrift

packages/cli/src/agent/update.md

@@ -302,39 +302,39 @@ removes the emptied legacy directory. A test that matches no rule is
 left where it is. `check` refuses to run until the project is migrated,
 logged in or not, and names `init`. Commit the moved files.
 
-**Only if `loggedIn` is `true` in `%(TASKLESS_CLI)s info --json`:** the
-CLI now speaks the Taskless v2 rule API, which addresses a rule by its
-own id (its directory name under `.taskless/rules/<engine>/`) and checks
-every issued rule against what Taskless issued. Logged out, nothing is
-checked, runtime rules are skipped as before, and none of the four
-entries below applies.
-
-- **Rules issued before 0.12.0 are treated as locally written.** They
-  came through the v1 API, which v2 does not know, so reconcile answers
-  them `unknown` and nothing can restore them. An ast-grep or Vale rule
-  keeps running, as any rule you wrote yourself. A runtime rule does
-  not: an `unknown` runtime rule never executes, so `check` skips it and
-  names it in `skipped` under `--json`. Regenerate each one with
+**Then run `%(TASKLESS_CLI)s check --json` once, and act on what it
+reports.** The CLI now speaks the Taskless v2 rule API, which checks
+every rule Taskless issued against what it issued, so `check` itself
+says whether any rule needs attention. If none of the following appears
+in its output, there is nothing to do. That includes every run that is
+logged out, where nothing is checked.
+
+- **"is a copy of Taskless rule `<source>`"** (in `failures`, `notices`,
+  or a `skipped` reason): the rule carries a file Taskless issued to
+  another rule, so it did not run. If the message says the source "was
+  deleted", run `%(TASKLESS_CLI)s rule restore <source>`; either way,
+  delete the copy. Never restore the copy's own id.
+- **"was edited since Taskless issued it"**: run
+  `%(TASKLESS_CLI)s rule restore <ruleId>` rather than editing it back
+  by hand. It writes only bytes whose signatures verify, and on a plan
+  without rule recovery it prints how to recover the rule from git
+  instead.
+- **A runtime rule in `skipped` with "not issued by the rule service"**:
+  it was generated before 0.12.0, through the v1 API, and v2 cannot
+  vouch for it, so it never runs. Regenerate it with
   `%(TASKLESS_CLI)s agent create-remote-rule`, then delete the old
-  directory.
-- **An edited issued rule fails `check`.** An edited ast-grep or Vale
-  rule does not run and fails the run, naming each changed, removed or
-  added file; an edited runtime rule does not run. Do not edit a rule
-  back by hand: run `%(TASKLESS_CLI)s rule restore <ruleId>`, which
-  writes only bytes whose signatures verify. On a plan without rule
-  recovery it prints how to recover the rule from git instead. `check`
-  itself never rewrites a rule.
-- **A copied or renamed issued rule fails `check` too.** A rule under a
-  new id that still carries a file Taskless issued to another rule does
-  not run, and the failure names the rule it came from. If the original
-  was deleted, the pair is reported as one rename: restore the original
-  with `rule restore <originalId>`, then delete the copy. Never restore
-  the copy's own id.
-- **`rule create --json` prints `requestId`, not `ruleId`.** The old
-  field always held the request id. The ids of the rules written are in
-  `rules`, and those are what `rule improve`, `rule restore`,
-  `rule revisions` and `rule rollback` take. Update anything that read
-  `ruleId` from `rule create`.
+  directory. An ast-grep or Vale rule from before 0.12.0 keeps running,
+  as a rule you wrote yourself, and needs nothing.
+- **"was issued for this repository but is not in .taskless/rules/"**:
+  run `%(TASKLESS_CLI)s rule restore <ruleId>` to bring it back, or
+  ignore it if the rule was removed on purpose.
+
+`check` never rewrites a rule itself; each fix above is a command you
+run. Separately, **`rule create --json` prints `requestId`, not
+`ruleId`**: the old field always held the request id. The ids of the
+rules written are in `rules`, and those are what `rule improve`,
+`rule restore`, `rule revisions` and `rule rollback` take. Update any
+script that read `ruleId` from `rule create`.
 
 **Files over 128KB are linted again.** 0.11.2 skipped any target file
 over 128KB that a matcher's section reached, naming it in a `notices`