1.x security backport gap (commit ad353ff71 missing acceptNameSet + URL char rejection)

## Summary

Commit `ad353ff71` on `alibaba/fastjson` (2026-07-29, *"fix: strengthen autoType type name validation and whitelist verification"*) claimed to backport [fastjson2 #7703](https://github.com/alibaba/fastjson2/pull/7703) to 1.2.83, but the 1.x code path only implements **one** of the three hardening steps described in the commit message.

`alibaba/fastjson` was archived the same day the partial backport was merged, with the description *"FASTJSON 2.0.x has been released, faster and more secure, recommend you upgrade."* This issue is filed on the 2.x repo because that is now the only active fastjson repository where the gap can be tracked.

## What's missing on the 1.x code path

| Step | fastjson 2 (✓) | fastjson 1 (✗) |
|---|---|---|
| `acceptNameSet` parallel to `acceptHashCodes`, so a rolling-hash collision cannot whitelist a type by itself | ✓ | ✗ |
| Reject URL-special characters (`:`, `!`) at the type-name entry points, so a non-class-name string (e.g. a `jar:` URL) cannot reach the class loader | ✓ | ✗ |
| Accept PREFIX does not cover ClassLoader / DataSource / RowSet gadget base types; only an accept entry naming the type in full is an explicit opt-in | ✓ | ✓ (the third bullet in the commit message says *"An accept prefix no longer covers ClassLoader/DataSource/RowSet gadget base types; only an accept entry naming the type in full is an explicit opt-in"*; reading the diff confirms the third bullet landed in 1.x; the first two did not) | ✗ |

## Why this matters

- **Hash collision whitelist bypass.** Without `acceptNameSet`, an attacker who can craft a type name whose rolling FNV-1a hash collides with a registered accept hash bypasses the whitelist, since the only check is `Arrays.binarySearch(acceptHashCodes, hash) >= 0`. Adding `acceptNameSet` and requiring the matching prefix to be present there closes this off.
- **URL-shaped string reaching the class loader.** A type name containing `:` or `!` is not a valid Java class name, but `TypeUtils.loadClass` and `ParserConfig.checkAutoType` would still pass it through to `ClassLoader.loadClass`. fastjson 2 already rejects these; fastjson 1.x does not.
- **1.x users have no upstream patch channel.** The `alibaba/fastjson` repo is archived and read-only. Anyone still on the 1.x line is exposed to the gap above with no way to receive a fix from the upstream maintainers.

## Completed patch

The two missing steps have been implemented in a fork branch and pass 10 dedicated tests (no regressions in 80+ existing parser/autoType tests):

- **Branch**: https://github.com/DenceChen/fastjson/tree/security/accept-name-set-validation
- **Tag**: `v1.2.84-security-backport` on the same fork
- **Gist (patch file)**: https://gist.github.com/DenceChen/d4370889ca70a0fe7238d1e182172517
- **Fork README documenting the patch**: https://github.com/DenceChen/fastjson/blob/security/accept-name-set-validation/SECURITY-PATCH.md

The patch is also at `src/test/java/com/alibaba/json/bvt/issues_1_2_x/issues3899/ParserConfigAcceptNameSetTest.java` in the fork, with coverage for:
- rolling-hash collision without accept text rejected
- `addAccept` normalises `$`-segments to dotted form
- `addAccept` deduplicates under normalization
- type names with `:` or `!` rejected by `checkAutoType` and `TypeUtils.loadClass`
- accept PREFIX does not authorise `ClassLoader` subclasses (full-name accept does)
- accept PREFIX does not authorise `DataSource` / `RowSet`

## Proposed actions

1. Reference this gap in fastjson2 release notes so 1.x users know to apply the fork patch or migrate to 2.x.
2. If anyone in the fastjson org wants to commit the fix on a maintained mirror of 1.x, the patch above is ready.
3. (Optional) Apply the same hardening shape to any other maintained 1.x forks (e.g., community patches) so users who can't migrate to 2.x immediately have a documented path forward.

## Disclosure

Filed as a public issue rather than via the security disclosure channel because `alibaba/fastjson` is archived and there is no upstream patch path. The fix is in a public fork and gist, so the gap is already disclosed.

Start by comparing fastjson2 #7703 with the fork patch and inspect the reported ParserConfig.checkAutoType and TypeUtils.loadClass entry points. Run src/test/java/com/alibaba/json/bvt/issues_1_2_x/issues3899/ParserConfigAcceptNameSetTest.java and the existing parser/autoType tests; done means the missing hardening is validated and a maintained upstream path or release-note action is identified.

Written by the indexing model from the issue text.