Decide how to wind down Pleasantest: hand off, deprecate, archive?

We've stopped actively maintaining Pleasantest, but we haven't actually decided *how* to wind it down — and right now the project is in the worst state for that: it looks alive from the outside while nothing is happening inside. This issue is to make that decision deliberately rather than by drift.

Renovate was just disabled here (#793) as part of a wider config migration. That stopped the dependency noise, but it's a maintenance decision, not a wind-down decision. The rest is still open.

## Where things actually stand

| | |
|---|---|
| Last substantive commit | **2024-08-01** (~2 years ago) |
| Last npm publish | **v5.0.0, 2024-07-30** |
| Unreleased work on `main` | Nothing meaningful — 2 commits, a dependency bump and #793 |
| npm downloads | **~281/month, ~39/week** |
| Open issues | **20**, all from 2021–2023 |
| Open PRs | 4 — three stale Renovate PRs (#789, #791, #792) plus #747 |
| Repo state | Public, not archived |

Two numbers matter most. **281 downloads/month means real people are still installing this** — a small number, but not zero, and none of them have any signal that it's unmaintained. And **20 open issues** are effectively 20 open promises we aren't going to keep.

## Decisions to make

These aren't mutually exclusive, and the ordering matters.

### 1. Do we look for a new maintainer first?

Worth a deliberate yes or no rather than skipping past it. There's a real feature backlog and a small but genuine user base, so it's plausible someone would want it. If we do ask, it has to happen **before** archiving, since archiving locks the issue tracker where that conversation would take place.

If someone does take it over, the answer to everything below changes — transfer the repo and the npm package rather than shutting down.

### 2. `npm deprecate` — the only option that reaches users

This is the one that's easy to overlook. Archiving a GitHub repo signals to people who *visit the repo*; most consumers never do. They see `npm install` output. `npm deprecate pleasantest ""` puts a warning in front of every install and on the package page.

If we do this, the message should ideally point somewhere. Worth deciding what we recommend instead — Vitest browser mode and Playwright component testing are the obvious modern candidates for "real-browser tests with Testing Library", but someone should confirm what they'd actually steer a user toward before we put it in front of every installer.

Deprecation is reversible (`npm deprecate pleasantest ""` clears it) and doesn't require archiving.

### 3. Archive the repo?

Makes the status unmistakable on GitHub and closes the 20 open issues honestly rather than leaving them to rot. Read-only, so no new issues or PRs. Reversible if a maintainer appears.

The argument against doing it immediately is that it removes the venue for a hand-off conversation — so if we want #1, this comes after.

### 4. Tidy the open PRs?

The three stale Renovate PRs will now sit open forever, since a disabled Renovate won't clean up after itself. Closing them with a pointer to #793 costs nothing and makes the repo state legible. #747 is a human PR and deserves an actual reply either way.

## A suggested sequence

Offered as a starting point to react to, not a decision:

1. **Deprecate on npm now.** It's the cheapest step, reaches the actual users, and is honest regardless of what we decide later.
2. **Post a short call for maintainers** here and in the README, with a deadline (say 60 days).
3. **Close the stale Renovate PRs** and reply to #747.
4. **After the deadline**, either transfer to whoever stepped up, or archive the repo and close the remaining issues with a note pointing at the recommended alternative.

That way users get told immediately, the door stays open for a hand-off for a bounded period, and we end in a clean state either way.

## What needs a person

- [ ] Do we want to seek a new maintainer, or is this a straightforward shutdown?
- [ ] What do we recommend users migrate to? (needed for the deprecation message)
- [ ] Approve deprecating on npm
- [ ] Decide whether and when to archive
- [ ] Close the stale Renovate PRs, reply to #747

Start by reviewing the README and the current npm package status, then assess the proposed maintainer handoff, deprecation, archive, and open-PR cleanup sequence. Done means the project has an agreed wind-down or transfer decision, a user-facing recommendation, and clear actions for the remaining issues and PRs.

Written by the indexing model from the issue text.