Contribute Swift fuzz targets for the OCI parsing code (continuous fuzzing via OSS Fuzz)

Hi, I'd like to contribute continuous fuzzing coverage for this project and would like your input on the best way to land it.

**What I have:** five libFuzzer targets written in Swift that decode arbitrary bytes through the OCI parsing code in ContainerizationOCI:

* image manifests (config and layer descriptors)
* image indexes (platform entries per manifest)
* full image config documents (rootfs, history)
* runtime spec documents (process, mounts, annotations)
* image reference strings through `Reference.parse`

Each target walks the decoded values and re encodes them to exercise the full Codable path. Seed corpora of valid documents are included, and everything builds and runs on Linux with Swift 6.2 (needing the libarchive, bzip2, lzma and openssl development packages).

**Why I'm asking first:** I opened an integration for this project in Google's OSS Fuzz program (google/oss-fuzz#16070) and the reviewer's policy is that the fuzz target sources should live in the upstream repository, with maintainer awareness, rather than in the oss fuzz repo itself. The gRPC Swift package follows this layout with a FuzzTesting sub package, and that is the arrangement I'd propose here: the five targets as a small sibling Swift package inside this repository, with the oss fuzz build cloning this repo and building that package.

**Questions:**
1. Would you welcome this contribution, and do you have a preferred location for it (for example a top level `FuzzTesting/` directory)?
2. Any requirements on my side regarding contribution process, license headers, or CI wiring you'd want alongside it?

For context on the kind of results this testing can produce: the same approach on the taglib audio metadata library found an undefined behavior issue in its ASF parser within the first minute of fuzzing (taglib/taglib#1429, fixed in taglib/taglib#1430), which is the sort of early catch continuous fuzzing gives parsing code that handles untrusted input.

Happy to send the package as a pull request once you confirm the approach. cc @dcantah

Start with the ContainerizationOCI parsing entry points and the Reference.parse path described in the issue, then review the proposed top-level FuzzTesting package layout and the OSS-Fuzz integration. Done means the five Swift libFuzzer targets and seed corpora are accepted upstream, build and run on Linux with Swift 6.2, and have an agreed OSS-Fuzz wiring approach.

Written by the indexing model from the issue text.