Avoid stacktrace when bots send commands

[arancaytar]

Relevant part of the stacktrace

/home/keira/bots/huntress/vendor/sylae/huntress/src/Huntress/Permission.php:290

Huntress\Permission::filterRole(): Argument #1 ($target) must be of type CharlotteDunois\Yasmin\Models\GuildMember, CharlotteDunois\Yasmin\Models\User given, called in /home/keira/bots/huntress/vendor/sylae/huntress/src/Huntress/Permission.php on line 217

#0 /home/keira/bots/huntress/vendor/sylae/huntress/src/Huntress/Permission.php(217): Huntress\Permission->filterRole()
#1 /home/keira/bots/huntress/vendor/sylae/huntress/src/Huntress/Permission.php(156): Huntress\Permission->check()
#2 /home/keira/bots/huntress/src/Huntress/Plugin/Role.php(113): Huntress\Permission->resolve()

It looks like the assumption is that $this->context->user (when passed to Permission::filterRole()) is a GuildMember. But it's a bit odd, because in Permission::sendUnauthorizedMessage() that type is explicitly checked.

Specifically, this came up in a case where a !role command was proxied, which can't work in any case.

So I guess some of our options here are to:

• ignore commands from bots entirely
• specifically ignore !role commands from bots (since these would target the bot and not the user that was proxied)
• make Permission::resolve() (or an earlier function in Permission) check the type of the EventData;:$user variable and reject if it's not a GuildMember?

[sylae]

in this case the offending message was from a webhook, which isnt a GuildMember. normal bot users will still be GuildMembers. easiest way to check is $user->webhook iirc, which i'd be more than happy blanket denying somewhere in HPM.

Easiest way, i think?: Anything that depends on a user permission (ie addMemberContext or addMessageContext iirc) should probably throw an exception if it gets a webhook. Stuff that doesnt require a user context (some modules use HPM as a janky config store for channel/guild processes) should be fine with webhooks tho