gitea: the token needs read:user, not just write:repository and write:issue

Deployed #49 and the watcher immediately broke: GET /user/repos answered 403,
'required=[read:user]' — confirmed live against the running forge (1.27.3).
That route sits under gitea's user scope category despite listing
repositories, not repository as assumed.

Also gives the fake forge real scope enforcement on /user/repos, which is
why the original PR's test suite didn't catch this: it only checked the
token's value was valid, never that it carried the required scope.

modules/gitea/token.ts

@@ -28,12 +28,15 @@ export const TOKEN_NAME = "mesh-tools";
 
 /**
  * The least the fifteen tools and the watcher need (gitea's route groups, 1.20+ scoped tokens):
- *   write:repository — list/create/delete repositories, pull requests (list/get/open/merge), and
- *                      the watcher's /user/repos poll;
- *   write:issue      — issues, comments, labels.
- * Nothing under /admin, /orgs or /users — the escape-hatch tool reaches only what these two cover.
+ *   write:repository — create/delete repositories, pull requests (list/get/open/merge);
+ *   write:issue      — issues, comments, labels;
+ *   read:user        — GET /user/repos, which the watcher's poll and gitea_list_repos both call.
+ *                      It sits under the `user` category despite listing repositories, not `repository`
+ *                      — confirmed against the running forge (1.27.3), which answered
+ *                      `required=[read:user]` to a token carrying only the other two.
+ * Nothing under /admin, /orgs or write:user — the escape-hatch tool reaches only what these three cover.
  */
-export const TOKEN_SCOPES: readonly string[] = ["write:repository", "write:issue"];
+export const TOKEN_SCOPES: readonly string[] = ["write:repository", "write:issue", "read:user"];
 
 /** Where a client's token comes from, and what to do when the forge says it is wrong. */
 export interface TokenSource {