Not sure how I feel about the red, maybe it'd work better as green like the other labels?

This is a lot of work! Well done :)
The majority of these comments are code consistency issues (bad indentation in places) or missing typing. Some are optimizations or code movement. The biggest bit of feedback is about presentation, which can also be addressed as a follow-up change if needed (and we can discuss options in Slack for this as well).

Should have mentioned here instead of the change introducing the widget but to avoid shifting the layout or reserving space, can we badge these onto the thumbnail instead? Overlay the top-left of the thumbnail a bit?

All new variables (and any being modified) should have a type when it can't be inferred (by being directly assigned something that does have an explicit type).
Same below.

This can be done as one statement with a list comprehension, which should be a bit faster.
In fact, if you do that, you can avoid the [] + above and just concatenate that list with this, giving a brand new list.

We fetch this from the data and then modify it below, which probably isn't safe.

Missing a type.

This might actually be better as a list comprehension. If you go that route, the other comments here won't apply.
But the nice thing there is, you don't have to store pending_deletion_attachments and then do the conditional below. You just concatenate above with data.all_file_attachments.

Blank line between these.

No parens on the conditional here.

Can you add this in alphabetically? I know this dictionary's a bit of a mess, but it'd be a step toward the right direction.

Missing the last : in :py:class:, and missing a trailing period.

These should all be in /** form.

I mentioned in another change that we should probably slugify the IDs, avoiding the temptation to use them as labels and to make them more useful in certain conditions. Just a note that they'd need to be updated here as well.

This should be on the next line, since it's a multi-line comment.

Summary should be on the next line.

The callback should align with other parameters.

I wanted to check a couple things with this signal. I note this is happening in-between removing and adding attachment information. I assume this order is important. Can we document that here, and what the responsibility is expected to be of the signal handler?
Also, replaceAttachment is like an action-invoking signal, rather than a notifying signal, which is why I assume (at the point I'm at in the review) that this is an important part of the replacement step. If it's meant to be a notifying signal, we should probably call it attachmentReplaced.

Comment contents should start on the next line.

No blank line here.

Same here.

The ? and : should align with the value being checked.
Actually, looks like we compute this in other places. Let's pull that result out into a variable and reuse it.

A few notes:

The <span> should be indented one space.
We want this to be described as a button in the accessibility tree. The <a> will need to be <a role="button" href="#"> to make that happen, and the .fa should be <span class="..." aria-hidden="true"></span>.

We can probably combine this into one statement, make sure the result is only computed and set once.

Indentation issue with the comment.

We access this.model three times. Let's pull it out into a local variable.

This should be formatted in the usual way, with ? and : being aligned with the start of the condition.

I don't think a Set buys us anything here. We know the entirety of the list of possible values, and it's a lot cheaper to check them one-by-one than to build a Set and check it each time this function is called.

Since _ isn't free, we want to avoid using and then overriding it. How about:

const deleteText = (draftStates.has(state)
                    ? _`Delete`
                    : _`Delete Draft`);

We use this.model several times in this method, so let's pull it out into a local variable.

You can use the set(key, value) form here and below, which is a bit cheaper when there's only one thing being changed.

We use this.model several times in this function, so let's pull it out into a local variable.

We use this.model several times in this method, so let's pull it out into a local variable.

When using template literals, every single piece of whitespace across lines is preserved, newlines included. We should avoid that here.
Also, nobody will see the log output unless they're us, so we should instead display an alert.
(Ideally we'd have something better than alert(), but that's the best option we have at the moment.)

We access this.#fileAttachmentThumbnailViews on every line, so let's pull it out into some views local variable.

If we're not writing to this, let's use Mapping instead of Dict.

Missing a type.

Our standard for list comprehensions are in the form of:

[
    value
    for value in loop
    if conditions
]

Is there any situation where a file can be removed and another added to this list, resulting in the same length but different contents?

There's an old typo here, if you don't mind changing it while modifying this line. "it's" should be "its".

The ? false indicates we can just do this as a boolean condition.

this.model.get('state') != this.states.PENDING_DELETION && options.canEdit

Ship It!