[arthurscchan]

This PR moves all the OSS-Fuzz fuzzers to the upstream storage for easier management. This PR works together with OSS-Fuzz (google/oss-fuzz#16274) to accommodate the moving of fuzzers upstream.

Of course, this is only a suggestion. If the maintainers would prefer the fuzzers to remain in OSS-Fuzz, I am happy to keep the current setup and to ping the relevant maintainers for review whenever I add new fuzzers later in the process.

Thank you for considering this, and I would welcome any feedback on the preferred approach.

Remark: After this PR is accepted and merged, there will be additional PRs for adding new fuzzers for this project later.

[rwgk]

Drive-by comment:

I was wondering why this is here, and that got me started on long-overdue, major maintenance work on tests/test_gil_scoped.py: #6211, #6212

(I'll come back to the fuzz part of this PR asap.)

[rwgk]

Thanks for proposing this! Keeping the fuzzers alongside the code they exercise would let us review and update both together.

My concern is that this PR adds the source file without integrating it into our build or tests. Changes in either pybind11 or the OSS-Fuzz environment could then break the harness while all pybind11 CI checks remain green. Before we take ownership of this code, I’d like us to establish a sustainable way to build, exercise, and maintain it.

I don't have experience working with fuzzers, so the requests below were mostly written by codex GPT-6.1-Sol ultra, with small manual edits:

Could you please add the following?

1. A supported build target for the harness. Ideally, our tests and OSS-Fuzz would use the same build rule. Making this optional and enabling it in one suitable CI configuration would be sufficient; we don’t need LLVM dependencies throughout our test matrix.

2. A small checked-in corpus and an automated replay test. This should exercise the actual fuzz callback, with inputs covering both successful operations and expected Python exceptions. There should be at least one CI job.

3. An automated check of the OSS-Fuzz integration. CIFuzz looks like a suitable option for building and briefly running the fuzzers on PRs. Another approach would also be welcome if it checks compatibility with the actual OSS-Fuzz build environment.

I’d also appreciate an explanation of which pybind11 behavior this harness is intended to exercise, particularly because it involves py::exec. When a failure is reported, we’ll need to reproduce it locally, understand the operations involved, and reduce it to a focused regression test. Could you document that workflow? Would fixed Python snippets with fuzzed arguments, or a selection of explicit binding and conversion operations, make failures easier to investigate? I’m open to your advice on the approach; I’d like us to establish that the harness provides useful coverage and that maintaining and debugging it will be practical for pybind11 contributors.