chore: OSS-Fuzz findings reach no maintainer and metadata is stale

ttf-parser has been a live OSS-Fuzz project since `google/oss-fuzz#12663` merged in January 2025, and the build is green. This repository was never told, and the project metadata has three problems. Filing so it is tracked rather than lost.

Current `google/oss-fuzz/projects/ttf-parser/project.yaml`:

```yaml
homepage: "https://github.com/RazrFalcon/ttf-parser"
main_repo: "https://github.com/RazrFalcon/ttf-parser.git"
language: rust
sanitizers:
- address
fuzzing_engines:
- libfuzzer
vendor_ccs:
- "david@adalogics.com"
- "arthur.chan@adalogics.com"
- "fuzzing@fuchsia.dev"
```

**1. No maintainer receives findings.** There is no `primary_contact` and no `auto_ccs`. OSS-Fuzz bug trackers are access-restricted to listed contacts for the 90-day embargo, so no ttf-parser maintainer can read reports against a crate with 92.9M downloads. This is the item that actually matters.

**2. Stale repository URLs.** `homepage` and `main_repo` point at `RazrFalcon/ttf-parser`. The clone still works through GitHub's redirect, but a stale `main_repo` degrades OSS-Fuzz's commit-range bisection when it tries to attribute a regression.

**3. The fuzz targets are vendored in oss-fuzz.** The `Dockerfile` ends with `COPY fuzz $SRC/ttf-parser/fuzz`, which overwrites anything the clone provides. That is why #179 — which added a `fuzz/` crate here — could not have taken effect, and why it was closed.

Fixing 1 and 2 is a small PR against `google/oss-fuzz` and needs only a maintainer email address. Fixing 3 means dropping the `COPY fuzz` line and the vendored tree there, then landing the targets here so this repo becomes authoritative; that ordering avoids a window where `$SRC/ttf-parser/fuzz` does not exist.

Related: #179 (closed), and `testing-tools/ttf-fuzz`, which has not compiled since 0.8.0 and should be deleted once a replacement lands.

Start by reading google/oss-fuzz/projects/ttf-parser/project.yaml and the OSS-Fuzz Dockerfile, then inspect the existing fuzz directory and #179. Confirm the maintainer contact and repository URLs, and understand the handoff order before changing the vendored targets. Done means findings reach a listed maintainer, metadata uses current URLs, and the authoritative fuzz targets are not lost during migration.

Written by the indexing model from the issue text.