Why `requiredPl` is always requires `state_default`?

Nobody has claimed this yet.

The problem is because `state_default` is so general and could be better if `requiredPl` requires something concrete instead of `state_default`.

[There it is][search].

Currently I need following config to setup bot without messing with moderators or remapping other levels:
```jsonc
notifications.room: 20
state_default: 20 // why?!
content.events."uk.half-shot.matrix-hookshot.feed": 20
unsigned.events."uk.half-shot.matrix-hookshot.feed": 20
unsigned.users."@feeds:integrations.ems.host": 20
```

[search]: https://github.com/search?q=repo%3Amatrix-org%2Fmatrix-hookshot+%22state_default%22&type=code

- - -

> [spec](https://spec.matrix.org/v1.19/client-server-api/#mroompower_levels):
> Except for membership events and redactions, the level required to send a certain event is governed purely by events, state_default and events_default. If an event type is specified in events, then the user must have at least the level specified in order to send that event. If the event type is not supplied, it defaults to events_default for message events and state_default for state events.

For example `Feeds` sends only following types:
- `m.room.message`
- `uk.half-shot.matrix-hookshot.feed` (state)
- `io.element.integrations.installations` (state, setup, sent by user)

— There is no need to check `state_default` PL.

Start by tracing how requiredPl handles state_default and the configuration for Feeds. Compare that behavior with the listed event types and Matrix power-level rules; done means concrete event requirements no longer unnecessarily require state_default.

Written by the indexing model from the issue text.