deprecate uni-require, and fix its stale repository metadata (#14)

The repo was renamed `uni-require` → `esm-plus`, but
`packages/uni-require/package.json` still names the old path in
`homepage`, `bugs` and `repository`.

**This blocks the next publish.** npm verifies the sigstore provenance
bundle against `repository.url`, and the trusted publisher for
`uni-require` was re-registered against `cyberuni/esm-plus` on
2026-09-03. The banked `1.0.1` would have failed with:

```
E422 Unprocessable Entity - Error verifying sigstore provenance bundle:
Failed to validate repository information
```

Same fault that blocked `jest-watch-suspend` earlier today, reached by a
**rename** rather than a transfer. It hides the same way: GitHub
redirects the old repo path indefinitely, so the value looks valid in a
browser, in `gh`, and in `npm view` — it is only ever checked at
publish, against the OIDC claim.

`CHANGELOG.md` is deliberately untouched: historical release records
whose links still resolve through the redirect.

## Not in this PR

A separate, more serious bug exists in this package and needs a design
decision — `createRequire(import.meta.url)` in `index.js` and `const
uniRequire = require` in `index.cjs` are both bound to **uni-require's
own module scope**, not the caller's, so `uniRequire.resolve()` resolves
from the wrong place. That is the feature the README names as the
package's main benefit. Raised separately.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01ETjy9oQGyETyFmDBdR9Egz

Author: unional

packages/uni-require/README.md

@@ -1,5 +1,38 @@
 # uni-require
 
+> [!WARNING]
+> **Deprecated. Do not use this package.**
+>
+> `uniRequire.resolve()` — the capability this package exists to provide — has
+> never worked as documented. Both entry points bind `require` to *uni-require's*
+> own module scope rather than the caller's:
+>
+> ```js
+> // index.js
+> const uniRequire = createRequire(import.meta.url)  // uni-require's URL, not yours
+>
+> // index.cjs
+> const uniRequire = require                          // uni-require's require, not yours
+> ```
+>
+> So `uniRequire.resolve('./x')` resolves relative to `uni-require`, not to your
+> module. This is not fixable while keeping the API: an ES module cannot discover
+> its caller's URL.
+>
+> ### Use Node's own `createRequire` instead
+>
+> ```js
+> import { createRequire } from 'node:module'
+> const require = createRequire(import.meta.url)      // your URL — correct
+> ```
+>
+> Available since Node 12. It is one line, it is in the standard library, and it
+> resolves from the right place.
+>
+> The dual-packaging problem described below is also largely moot now: Node 22.12
+> and later support `require()` of an ES module directly.
+
+
 The `require()` function is not available for ESM package.
 
 But there are situation you need to use it,

packages/uni-require/package.json

@@ -8,13 +8,13 @@
     "import",
     "esm"
   ],
-  "homepage": "https://github.com/cyberuni/uni-require",
+  "homepage": "https://github.com/cyberuni/esm-plus",
   "bugs": {
-    "url": "https://github.com/cyberuni/uni-require/issues"
+    "url": "https://github.com/cyberuni/esm-plus/issues"
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/cyberuni/uni-require.git",
+    "url": "https://github.com/cyberuni/esm-plus.git",
     "directory": "packages/uni-require"
   },
   "license": "MIT",