Fix binary court report downloads

[alloutflo]

What github issue is this PR for, if any?

Resolves #7099

What changed, and why?

• Read the stored DOCX with File.binread, so the response body remains binary (ASCII-8BIT) instead of being tagged as invalid UTF-8 text.
• Pass #{@casa_case.case_number}.docx explicitly to send_data, so escaped characters in the request URL cannot alter the downloaded filename.
• Replace the empty temporary attachment in the request spec with a real DOCX fixture and verify exact response bytes, blob byte size, ZIP magic, and Content-Disposition.
• Use a case number containing # and a deliberately different stored blob name, so the regression covers the reported filename edge case.

The new example fails against the old controller implementation because the response has the wrong encoding and no explicit filename, then passes with this change.

How is this tested? (please write rspec and jest tests!) 💖💪

• bundle exec rspec spec/requests/case_court_reports_spec.rb:55 — 4 examples, 0 failures
• bundle exec standardrb app/controllers/case_court_reports_controller.rb spec/requests/case_court_reports_spec.rb — passed
• ruby -c for both changed Ruby files — passed
• git diff --check — passed
• Full spec/requests/case_court_reports_spec.rb: 27 examples passed; three unchanged index examples could not render because the local test setup did not contain the built application.js asset. The focused DOCX context and all changed-code checks pass.

Screenshots please :)

Not applicable; this changes the binary download response and request coverage, with no visual UI changes.

Feelings gif (optional)

AI disclosure: I used an AI coding assistant to help inspect the issue, implement the focused change and regression coverage, and run the checks listed above. I reviewed the final diff and test results before submitting.

[alloutflo]

CI note: the Brakeman failure is unrelated to this diff. Its only warning is EOLRails for Rails 8.0.5.1 reaching end of support on 2026-10-07, reported against the unchanged Gemfile.lock; there are no scan errors or controller findings. The latest Brakeman run on the same base commit (8e893b17) passed on 2026-08-07, so this appears to be time-dependent Brakeman/EOL-data drift rather than a regression in the binary download change. I have kept the PR focused instead of adding an unrelated dependency or ignore-file change.