Signing key disrepancy (between #main-key and none)

[ShadowJonathan]

We discovered this on akkoma; it seems that gup.pe isnt sending the #main-key attachment when sending requests to servers;

[09/Feb/2025:13:15:59 +0100] (0.675/0.000+0.674 s) - "GET /users/jo HTTP/1.1" 500 (45 B) {application/json; charset=utf-8} "-" "Guppe Groups/1.5.2 (+http://a.gup.pe)" {-%-} cc:"max-age=0, private, must-revalidate" => 192.168.178.251 (keyId=https://a.gup.pe/u/system_service)
[09/Feb/2025:13:16:28 +0100] (0.004/0.000+0.003 s) - "GET /users/jo HTTP/1.1" 500 (45 B) {application/json; charset=utf-8} "-" "Guppe Groups/1.5.2 (+http://a.gup.pe)" {-%-} cc:"max-age=0, private, must-revalidate" => 192.168.178.251 (keyId=https://a.gup.pe/u/system_service)
[09/Feb/2025:13:17:44 +0100] (0.003/0.000+0.003 s) - "GET /users/jo HTTP/1.1" 500 (45 B) {application/json; charset=utf-8} "-" "Guppe Groups/1.5.2 (+http://a.gup.pe)" {-%-} cc:"max-age=0, private, must-revalidate" => 192.168.178.251 (keyId=https://a.gup.pe/u/system_service)
[09/Feb/2025:13:19:38 +0100] (0.003/0.000+0.002 s) - "GET /users/jo HTTP/1.1" 500 (45 B) {application/json; charset=utf-8} "-" "Guppe Groups/1.5.2 (+http://a.gup.pe)" {-%-} cc:"max-age=0, private, must-revalidate" => 192.168.178.251 (keyId=https://a.gup.pe/u/system_service)

However, when fetching keys from the gup.pe server itself, it does include #main-key; https://a.gup.pe/u/system_service#main-key

This causes problems with servers which expect a 1:1 association, while this effectively returns a different signing key when fetching the original account, and the likes.

https://akkoma.dev/AkkomaGang/akkoma/issues/858