<!--
This is the human half of "verified on every release".

CI can only prove the pinned hash matches what the registry serves. It cannot
tell you what that code DOES. Everything below is the part only a person can
do. A merged PR here makes code installable on other people's machines under
unom's badge -- treat it accordingly.
-->

## What changed

- **Package:**
- **Version:** `` -> ``  (previous pinned version -> new pinned version)
- **Type:** <!-- new plugin / version bump / metadata only / security advisory -->

## Diff reviewed

**Tarball compared:** <!-- paste the command you ran, e.g.
  npm pack @punktfunk/plugin-foo@0.2.0 --registry https://git.unom.io/api/packages/unom/npm/
  npm pack @punktfunk/plugin-foo@0.3.0 --registry https://git.unom.io/api/packages/unom/npm/
  then extract both and: diff -ru foo-0.2.0/ foo-0.3.0/
For a NEW plugin there is no previous version -- read the whole thing instead and say so. -->

```
(summary of what actually changed in the published artifact)
```

## Review checklist

Tick each box only after you have personally checked it **against the published
tarball**, not against the git repo. The tarball is what users execute; the repo
is only evidence about it.

- [ ] **Diffed against the previously pinned version.** I compared the new
      tarball to the last version pinned in this index and read every change.
      (New plugin: I read the entire published tarball.)
- [ ] **No unexpected network endpoints.** Every host the code contacts is
      accounted for by the plugin's stated purpose. I grepped for URLs, IPs,
      `fetch`/`http`/`net`/`dns`/websocket use, and found no telemetry,
      analytics, or beaconing that is not disclosed.
- [ ] **No filesystem access beyond the stated purpose.** Reads and writes stay
      within what the plugin is for. No access to credentials, SSH keys, browser
      profiles, host config, or unrelated user data.
- [ ] **No obfuscated or minified code where source is expected.** Everything is
      readable. Nothing is base64/hex blobs, `eval`, `new Function`, dynamic
      `require` of computed strings, or a bundled build I cannot trace to source.
      Vendored/bundled dependencies are declared and justified below.
- [ ] **No install lifecycle scripts.** package.json has no `preinstall`,
      `install`, `postinstall`, `prepare`, or `prepublish` that executes code on
      the user's machine at install time.
- [ ] **Dependencies reviewed and justified.** I reviewed every added or bumped
      dependency: each is necessary, from a plausible source, and not
      typosquatting a well-known name. New transitive weight is proportionate.
- [ ] **Pinned integrity matches the registry.** I fetched `dist.integrity` from
      the registry myself and compared it to the value in this PR -- I did not
      only trust CI.
- [ ] **Version is an exact semver.** No range, no `latest`, no `v` prefix, no
      wildcard. One immutable version.
- [ ] **Metadata is accurate.** Title, description, icon, author, homepage,
      license, `platforms`, and `minHost` all match reality.
- [ ] **`reviewedAt` is today's date** and reflects when *this* review happened.

### Dependencies added or changed

<!-- list each, with why it is needed. "none" is a fine answer. -->

### Anything that gave you pause

<!-- Note anything odd you decided was acceptable, and why. If nothing, say so
     explicitly -- "nothing" is a real signal, a blank field is not. -->

---

<!--
Reviewer: if any box cannot be honestly ticked, do not merge. An unmerged PR
costs one release cycle. A bad merge ships code to every host that trusts this
index, signed by unom's key.
-->