I haven't gone through the tree to see if anything's missing. This looks pretty thorough, though.
There's some consistency issues between this and previous release notes that I want to hammer out, in terms of section ordering, summary / description breakdowns, and the ways we name things.
For summaries, we want to aim to be skimmable. This is good for readers and for Google SEO. Simple summary that's explanatory enough, detailed description broken into smaller chunks of paragraphs and/or bullet lists. For now, look at the 6.0 docs. We also need to ensure that a person can get enough information out of any given entry to learn about the fix, other than just the "vague thing about this feature is fixed." That includes us when trying to track down when we actually addressed some fix we need to backport to somebody.
For sections, I mention this in another comment, but I'll put a task on my plate to get standard templates for future releases going so it's easier to just start plugging things in.

A couple things stood out to me generally in this change:

We're quoting a lot of UI concepts. We haven't historically done this, instead just letting Proper Nouns speak for themselves. If we do want to label anything, we should use :guilabel:
We've never capitalized "Review requests" as "Review Requests". I'm not opposed, but it's a new thing, and we should decide if that's how we want to address it 100% of the time going forward.

As a reminder, we need to document any removed code that was deprecated, and any new deprecations, for extension authors.

Should be _clean-orphaned-data.

Let's use a literal here.

We should list the dropped version.

The "which" kind of reads oddly to me, but I also think we can be a bit more clear in general on this. Maybe:

Review Board now supports displaying, reviewing, and diffing certain types of binary files included as part of your changes posted for review.

At the moment, this is limited to image files, but support for additional file types are in the works.

Let's link to the RBTools page.

Let's capitalize this as "Dark Mode" wherever we reference it. This is the name of the feature, not just a dark mode.

Same with "Light Mode".

Going with more of a marketing-focused view, how about:

Diffs can now be reviewed on mobile devices.

We should link both.

Pytest_-based.
We should also link Nose, for reference/context.

This is a bit verbose for a summary (3 lines is a lot). These should all be clearly skimmable.
How about something like:

Extensions can now be built using modern TypeScript, JavaScript, and CSS tools.


Then we can add a version of this paragraph as the first in the description.

We should link each of these tools. Even people who may be familiar with Babel may not know what Rollup or TSC is (we could say "TSC (the TypeScript compiler)").
Also, .npm-workspaces is our creation, so we need to at least mention that this is a directory at the root of their source tree.

"Web API" also gets its own top-level section, after "New Features".
I'll work on a standard template after this release, to help with future release notes.

We should link to HSTS, and maybe the rest, to help admins learn about this.

There's a lot of good information in here, and we should add a task to add this to the docs.
For this paragraph, I feel like we should split this into the explanation of the setting and then into the conditions around it ("The particular settings will depend ... See the Django documentation ...")
We should also link to the Django documentation when we say it.

settings_local.py.

We should be able to reference this module directly up above, since Django's in the intersphinx. We can still give it this title.

Can we describe this briefly?

Let's use :term: here around "Local Site" so that users can learn what that means. It'll link to the glossary.

I think we need to clarify this a bit. It can read both as "Fixed removing data" as in we fixed the operation of removing data, or as in we fixed it from removing data (which sounds scary).

Too many blank lines.

Feels like a word is missing here. "Fixed removing <what> when deleting ..." ?
This would be subject to the same clarification as above.

Or on the CDN. Maybe "file storage"?

We should use a literal here.
I feel like the library name isn't the highlight, though. We should just say that we fixed LDAP support.

We should use :guilabel: instead of quotes.

This could just be me being pretty sleepy, but I had to read this a couple times. I was reading it as "... which were creating with RBTools using ((Git or Mercurial) track commit history)".
Maybe:

When posting a change using RBTools with either Git or Mercurial, the review request will keep track of all the commits included in your change. This allows ...

"Previously" would be a good place to begin a new paragraph, since we just finished explaining the background leading up to this change.
Also, :guilabel: maybe for "Update Diff".

Do we have docs we can link to instead of using quotes?

:guilabel: would be better for these.

We're using "diff viewer" here but "Diff Viewer" below. We should make sure we're consistent everywhere.

Let's link to the release notes for 6 here.

This isn't reading right to me. The "back to the diff" part seems out of place. Maybe:

Fixed links from comments back to the diff when viewing commit ranges


Or something?

Can we clarify this? I'm not sure what this is saying.

Can we say how it displayed incorrectly, so it's more clear what the wrong behavior was?

We generally capitalize this as Issue Summary Table (and should here, since we're doing so with most other references).
We could link as well.

Maybe specifically say "web browser caching conflicts."

Maybe "Review UIs now display an error ..."

"Extensions" gets its own top-level section after "New Features".

We should link HideActionHook.

Just to help clarify this, maybe something like:

Fixed invisible links to file attachments without captions set in :guilabel:`Admin UI -> Database -> File Attachments`

We should explain what this means. It's too vague.

Good opportunity for :guilabel:.
Also, what kind of visual glitches?

:guilabel: would be good here, too.
And other widgets below.

We have a couple Docker things spread out. This should all be in a Docker section.

This should go in New Features somewhere, rather than getting its own top-level section.

This section traditionally goes before Bug Fixes.

Performance Improvements goes before Usability Improvements.

Let's use :term: for Local Sites.

Ship It!

Basically done, but there's a bit of organizational stuff left to help with reading through affected fixes.

I'd say this belongs more in Bug Fixes -> Integrations.

A lot of this section should be split into subsections, to ease scanning. I'd add:

Authentication (redirect loops)
Local Sites
Dashboard (includes other datagrids)
Diff Viewer
My Account

And some of these (like action-related things) can be put into Reviews.
It's okay if there's only one per section. The important part is making it easy to scan for the category of the bugs that were fixed. General should be as small as possible.

For the reference, we can use:

:doc:`Review Board 6 <6.0>`


(Double-check that the reference works, but that should be it.)

Anything referencing something on a class needs to have that Class.thing as a title.

General is usually first.

Debating on this, but maybe this should go in Reviews?
We've also historically had a Review Requests section, but it may be a bit redundant here.

Ship It!