fix(wiki,repo-sync): Gitea 認證缺值改詢問使用者

什麼：wiki 與 repo-sync 兩支技能在 GITEA_HOST／GITEA_TOKEN 無法解析時，原本只回報認證失敗；現在改為先走 jsc-ask:ask 詢問使用者。同步將 jsc-gitea 版本號由 0.0.4 升至 0.0.5。

為什麼：guidelines 的環境變數表規定無法解析的必要環境變數要詢問使用者，不能直接回報失敗；先前兩支技能的行為不符合 jsc-meta:skill-check 的稽核規則。

如何：在 skills/wiki/SKILL.md 與 skills/repo-sync/SKILL.md 呼叫 tools/gitea.sh 前，先檢查 GITEA_HOST／GITEA_TOKEN 是否可解析（含 tea login list 的備援 token），無法解析時依 jsc-ask:ask 的決策樹詢問使用者；同時將 plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 的版本號由 0.0.4 升至 0.0.5。

負責功能：Gitea 認證缺值改詢問使用者（wiki、repo-sync 兩技能共用的根因修正）。

skills/wiki/SKILL.md

@@ -11,7 +11,7 @@ Every wiki operation in the jsc skill set goes through this skill. One entry poi
 
 Different page types can live in different `{owner}/{repo}` repos, classified by page-name prefix: `QUESTION`, `PLAN`, `ANALYZE`, `MAINTAIN`, `REPO`, `LOG`, `LEARN`, `ERROR`.
 
-1. Before asking the user, inspect the current shell environment for the needed repo variables and Gitea connection variables: `JSC_WIKI_REPO_{TYPE}`, `JSC_WIKI_REPO`, `GITEA_HOST`, and `GITEA_TOKEN`. Use inherited shell values first; only ask when the needed repo cannot be resolved after that check.
+1. Before asking the user, inspect the current shell environment for the needed repo variables and Gitea connection variables: `JSC_WIKI_REPO_{TYPE}`, `JSC_WIKI_REPO`, `GITEA_HOST`, and `GITEA_TOKEN` (also check `tea login list` for a usable login token when `GITEA_TOKEN` is unset). Use inherited shell values first; only ask when the needed repo or connection value cannot be resolved after that check. `GITEA_HOST` and `GITEA_TOKEN` are both covered by this ask-if-unresolvable rule, the same as the wiki-repo variables below.
 2. Run `tools/gitea.sh wiki-repo {TYPE}` (TYPE = the page-name prefix). Allowed types are `QUESTION`, `PLAN`, `ANALYZE`, `MAINTAIN`, `REPO`, `LOG`, `LEARN`, and `ERROR`. Resolution order is `JSC_WIKI_REPO_{TYPE}` first, then `JSC_WIKI_REPO`. Never borrow another type's repo.
 3. On exit 3 (neither is set after env inspection), ask the user for that page type's `{owner}/{repo}` per the `jsc-ask:ask` rules, and suggest setting `JSC_WIKI_REPO_{TYPE}` (can differ per type) or `JSC_WIKI_REPO` (shared default).
 
@@ -30,4 +30,4 @@ Different page types can live in different `{owner}/{repo}` repos, classified by
 3. To update a contents page (`*_CONTENTS`): `wiki-get` it first, apply the template to append or modify, then `wiki-put` the whole page back. Never overwrite entries owned by others.
 4. Write all wiki content in UTF-8 Traditional Chinese, per the STE100 output rule.
 5. Prefer visual forms for page content: use mermaid diagrams (flowchart, sequence, gantt, pie) and markdown tables wherever the information allows. Plain running text is the last resort, kept short.
-6. Authentication fallback is built into `tools/gitea.sh`: on a missing GITEA_TOKEN or a 401/403 response it retries with the tea CLI login token automatically, so only report an auth failure when both paths fail.
+6. Authentication fallback is built into `tools/gitea.sh`: on a missing GITEA_TOKEN or a 401/403 response it retries with the tea CLI login token automatically. But before calling it, resolve `GITEA_HOST` and `GITEA_TOKEN` per rule 1: if `GITEA_HOST` is unresolvable, or `GITEA_TOKEN` is unset and no tea login token exists either, ask the user for the missing value per the `jsc-ask:ask` rules — same decision-tree pattern as the missing-wiki-repo case above — before calling `tools/gitea.sh`. Only report a genuine failure when the user has no answer to give or Gitea itself rejects the request (e.g. a 401/403 even after the tea fallback).