This logo is set by the person who sets up the Incoming Webhook in Microsoft Teams, it can't be set on our end by the RB integration. In my case I just uploaded our logo via the Microsoft Teams app. The admin could choose to not upload a photo, or upload a scaled down one, etc.

Ahh. Perhaps we can provide a recommended image for people?

That's a good idea. I'll try to do this in the docs.

On the djblets.integrations.Integration parent class, icon_static_urls is defined as an attribute instead of a method:
icon_static_urls: Dict[str, str] = {}
Mypy was giving me a "signature incompatible with supertype" error. I saw in RB we have a similar attribute -> method situation on the reviewboard.hostingsvcs.base.paginator.ProxyPaginator class, and there we use # type: ignore as well. I can add a comment here explaining why we do this.

OK, yeah, I've seen that. It seems like python hasn't yet solved the question of how typing should work for things that can either be a plain attribute or a property.

It's not that they haven't solved it, it's that it's considered explicitly to be type-unsafe and discouraged. Although that's an in-theory thing and sadly not practical.
It's considered a violation of the Liskov Substitution Principle (LSP), which type checkers are built around. The idea there is that you should always be able to substitute in an instance of a subclass in place of a parent of a class without breaking the program.
When you type attributes, you should be able to have the same types and behavior whether you're the class that defines the attribute or any subclass of that class.
As soon as you introduce a @property, you violate this. You now have complexity that may or may not guarantee compliance with LSP.
Three examples would be:

A @property with no setter (you've now removed the ability to set the attribute)
A @property with a setter where the value you set and the value you get are different (e.g., normalization is conducted)
A @property with a setter where the setter and getter work with different types.

Type checkers can't make guarantees here, so they just flat-out consider this to be a violation of the type.
That means that, to be compliant, we'd need to rethink some of how we tend to structure our classes. We may want to start moving toward get_*() methods that default to accessing a variable, for instance. Or we may just say, screw it, the theoretical shouldn't impact our practical.

Yeah, I can link to our MS Teams integration docs here instead of the MS_TEAMS_WEBHOOK_DOCS_URL.
In our docs we currently link to this same MS_TEAMS_WEBHOOK_DOCS_URL, which I'd like to keep there because otherwise we have to copy over a lot of information on how to set up the Incoming Webhook in Microsoft Teams (there are steps for the "classic" version of teams, and other steps for the "new" version).
Plus if the steps ever change, our information will be outdated and we may not notice for a while. In this case people would try our steps, find out that they're wrong, and then seek out the real MS teams docs. If we simply link to the MS Teams docs, and the link is not correct anymore, then people will still have seek out the real MS teams docs, but will do this right away instead of wasting time reading/following our outdated steps first.