fuzz: fix multipart fuzzer imports (StreamReader, CIMultiDict)

[soccerlover29]

What do these changes do?

Fix the fuzzers/multipart.py fuzzer so it actually runs. As written, it
crashes at startup, which would make the CIFuzz CI job (added in #12887) fail
its run step.

Two fixes:

1. class FuzzStream(StreamReader) uses StreamReader but never imported it.
   Added from aiohttp.streams import StreamReader.

2. HeadersDictProxy was constructed with a plain dict, but its __getitem__ calls self._md.getall(key), which only exists on CIMultiDict — so any header lookup crashed with AttributeError: 'dict' object has no attribute 'getall'.
   Wrapped the dict in CIMultiDict and added the import.

Are there changes in behavior for the user?

No.

The fix only touches a test/fuzzing harness under fuzzers/; it doesn't change aiohttp's runtime behavior or public API.

Is it a substantial burden for the maintainers to support this?

Not at all.

It is three lines added and one line changed in a single fuzzer file, using APIs already used elsewhere in the aiohttp codebase (aiohttp.streams.StreamReader, multidict.CIMultiDict). Both fixes are verifiable with the OSS-Fuzz build; no new dependencies or maintenance surface.

Related issue number

Complements google/oss-fuzz#15791 (the OSS-Fuzz migration ticket).
Full test details are in my comments on that issue and on PR #12887.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder

  • name it <issue_or_pr_num>.<type>.rst (e.g. 588.bugfix.rst)

  • if you don't have an issue number, change it to the pull request
    number after creating the PR

    • .bugfix: A bug fix for something the maintainers deemed an
      improper undesired behavior that got corrected to match
      pre-agreed expectations.
    • .feature: A new behavior, public APIs. That sort of stuff.
    • .deprecation: A declaration of future API removals and breaking
      changes in behavior.
    • .breaking: When something public is removed in a breaking way.
      Could be deprecated in an earlier release.
    • .doc: Notable updates to the documentation structure or build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and tooling. Changes in the test invocation considerations and
      runtime assumptions.
    • .contrib: Stuff that affects the contributor experience. e.g.
      Running tests, building the docs, setting up the development
      environment.
    • .misc: Changes that are hard to assign to any of the above
      categories.

  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

    Use the past tense or the present tense a non-imperative mood,
    referring to what's changed compared to the last released version
    of this project.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

_{Reviews (2): Last reviewed commit: "Apply suggestion from @Dreamsorcerer" | Re-trigger Greptile}