README: drop the commit bar that no longer exists, and the regeneration step nobody needs

Two stale instructions in the Contributing section, both of which now send a
contributor somewhere they do not have to go.

**The commit-count bar was removed on 2026-09-03** (issue #4196, reverted in
#4244) and both READMEs still said "at least 1 day old with 10 or more
commits". contributing.md was updated at the time; the README summary was
missed. A submission with nine commits would read that line and wait, or
resubmit work that was already acceptable.

**The regeneration step is no longer required.** The sentence told contributors
to run `node scripts/generate-readme.mjs` and commit the result, which was true
before the READMEs moved to being generated on main (#3832) and is now both
unnecessary and slightly harmful: a contributor who follows it commits a README
snapshot that main invalidates on its next merge, which is the failure that put
18 open pull requests on a red `READMEs match data/plugins` step. Both READMEs
now say the regeneration happens on main, that a local run is for previewing,
and that committing the result is still accepted but not required.

Both files are generated, so this only touched the hand-written region above
`<!-- BEGIN PLUGINS -->` and below the list; `generate-readme.mjs --check`
still exits 0, and awesome-lint passes.

Also corrected a measurement in contributing.md that had gone stale: the entry
cap's rationale quoted "of the last 100 merged pull requests, 92 added one entry
and 8 added two; none added three". Counted again today over the 100 most recent
pull requests that added entries: 88 added one, 3 added two and 9 added three —
so "none added three" is no longer true. The figure is now dated rather than
timeless. The rule is untouched; whether the allowance's stated purpose still
matches how it is used is a separate question, raised with the maintainer rather
than decided here.

README.md

@@ -4435,12 +4435,12 @@ description:
   zh: 一句话描述，以句号结尾。
 ```
 
-One file per plugin means two submissions never touch the same file, so PRs stop conflicting with each other. Run `node scripts/generate-readme.mjs` to refresh both READMEs, and commit the result.
+One file per plugin means two submissions never touch the same file, so PRs stop conflicting with each other. You don't need to run anything: both READMEs are regenerated on `main` after your PR merges. Regenerating locally to preview is fine, and committing the result is still accepted, but it isn't required.
 
 Your repo must:
 
 - declare a **`dsh.bundle`** manifest in `package.json` — `dsh.client` alone is not installable, and this is checked automatically on every PR
-- be at least **1 day old** with **10 or more commits** — brand-new repos can resubmit once they clear this
+- be at least **1 day old** — brand-new repos can resubmit once they clear this. (There is no commit-count bar: history length measures development habit, not quality.)
 - carry the [`dsh-plugin`](https://github.com/topics/dsh-plugin) topic
 
 Themes & skins: entries under **Themes & Appearance** power the Themes tab in `dsh-market` — one-click install/switch for users.

README.zh.md

@@ -4435,12 +4435,12 @@ description:
   zh: 一句话描述，以句号结尾。
 ```
 
-一个插件一个文件，两份投稿永远不会碰同一个文件，PR 之间不再互相冲突。执行 `node scripts/generate-readme.mjs` 重新生成两个 README，并把结果一起提交。
+一个插件一个文件，两份投稿永远不会碰同一个文件，PR 之间不再互相冲突。你不需要跑任何命令：两个 README 会在你的 PR 合并后由 `main` 重新生成。想在本地预览可以跑，把结果一起提交也照样接受，但不是必需的。
 
 你的仓库需要满足：
 
 - `package.json` 声明 **`dsh.bundle`** —— 只有 `dsh.client` 无法安装；每个 PR 都会自动校验这一项
-- 仓库**创建满 1 天**且**提交数 ≥ 10** —— 刚建的仓库达标后可以重新提交
+- 仓库**创建满 1 天** —— 刚建的仓库达标后可以重新提交。（没有提交数门槛：历史长短反映的是开发习惯而非质量。）
 - 已添加 [`dsh-plugin`](https://github.com/topics/dsh-plugin) topic
 
 主题/皮肤类插件：放进**主题与外观**分类，会自动出现在 [dsh-market](https://github.com/dsh-market/dsh-market) 插件市场的**主题 Tab**，用户可一键安装、切换。

contributing.md

@@ -147,7 +147,7 @@ A pull request may add **at most 3 entries**. Over that, CI rejects it and asks
 
 Reviewing a submission means reading the plugin's source and checking every claim in its description against it. That work is per-entry and does not get cheaper in bulk: a pull request carrying 127 entries is not one submission, it is 127 submissions wearing a coat, and the honest outcome is that none of them get read properly. / 评审一个投稿意味着读插件源码，并把描述里的每一句话对着代码核一遍。这是逐条的工作量，不会因为打包提交而变少：一个装了 127 条的 PR 不是一次投稿，而是 127 次投稿套了件外衣，诚实的结果是没有一条会被认真读完。
 
-Three is not a guess — of the last 100 merged pull requests, 92 added one entry and 8 added two; none added three. The allowance exists for the one shape that legitimately needs it: a monorepo whose subpackages are separately installable plugins. / 3 不是拍脑袋定的——最近 100 个已合并的 PR 里，92 个加了 1 条、8 个加了 2 条，没有一个加 3 条。留这个余量是为了一种确实需要它的情形：一个 monorepo 的多个子包各自是可独立安装的插件。
+Three is not a guess — when the allowance was set, of the last 100 merged pull requests 92 added one entry and 8 added two. Counted again on 2026-09-24, over the 100 most recent that added entries: 88 added one, 3 added two, 9 added three. The allowance exists for the one shape that legitimately needs it: a monorepo whose subpackages are separately installable plugins. / 3 不是拍脑袋定的——当初定下这个余量时，最近 100 个已合并的 PR 里 92 个加了 1 条、8 个加了 2 条。2026-09-24 重新数了一遍，最近 100 个「新增了条目」的 PR 里：88 个加 1 条、3 个加 2 条、9 个加 3 条。留这个余量是为了一种确实需要它的情形：一个 monorepo 的多个子包各自是可独立安装的插件。
 
 **If several plugins are yours, split *and* pick.** Send the ones you would keep if you could only keep a few, not everything that works. A reader opening a category needs "these are all worth a look", not "some of these are". / **如果多个插件都是你的，除了拆分还要挑。** 提交那些「如果只能留几个，你会留下的」，而不是所有能跑的。读者打开一个分类，需要的是「这些都值得一看」，而不是「这里面有几个值得一看」。