include rate limit groups in platform API implementation

breakout issue for this specific part of the overall "key handling improvement" workflow, initially defined in #71

> key limiting:
>
> #71 suggests we add a "platform features" column to the worker_oauth table where we store API keys. This would be for storing key pseudo-platforms (IE: the different request limits for each key type - gor github, these would be `rest` and `graphql`) these values would be used by keyman for rate limiting.
>
> For the purposes of this issue, I would call this "rate limit groups" instead, and i think they belong in the internal implementation, alongside other information like the platform name/type, rather than in a DB table, since they are basically fixed information that changes with the API (and should therefore live in the implementation code).
>
_Originally posted by @MoralCode in [#293](https://github.com/chaoss/CollectOSS/issues/293#issuecomment-4381634638)_

This should be done as part of the code implementing each platforms API (and integrated into keyman so workers can fetch the right API keys/groups for what they are doing)