GitHub Integration

[shivaraj-bh]

resolves #37

Summary by Claude Opus 4.6:

This PR adds GitHub App integration to Vira, enabling:

• Webhook event handling (PR events, push events, installation events)
• GitHub Check Run lifecycle management (queued → in-progress → completed)
• Fork PR approval workflow (same-repo PRs auto-build, forks require approval)
• Automatic repository management on app install/uninstall
• A new servant-github-webhook-simple package for type-safe webhook handling
• New UI: PR listings on Index/Repo pages, PR detail page (PullPage)

[shivaraj-bh]

@srid This PR has now reached alpha stage. I have generated a quick documentation with Claude Opus 4.6 here: https://github.com/juspay/vira/blob/dcc9a2fc7ae4bfb542909de70c6ccfa06be8fef8/docs/github-integration.md, for you to try it out, while I refactor before making the PR ready for review.

[shivaraj-bh]

FYI: I have been testing using a dummy GitHub App in shivaraj-bh/services-flake#20 (See check with label “Vira CI”)

[srid]

@srid
Merge branch 'main' into github

Had to do this in order to get new vira.hs format.

[shivaraj-bh]

@srid During the initial review over openspatial, you mentioned that an automated way of using the likes of https://smee.io for production would be nice.

There are three ways to go about this:

1. Host a webhook relay server like https://github.com/chmouel/gosmee to be publicly accessible. Add a home-manager service alongside vira that forwards webhooks from the server to the client.
2. Instead of webhooks, poll on https://docs.github.com/en/rest/apps/webhooks?apiVersion=2022-11-28#list-deliveries-for-an-app-webhook; Vira reads the webhook events that GitHub tried to send us (and failed since Vira isn’t public). There is a trade-off though: Either Vira stores in its acid-state the last event that was processed or we store an in-memory state, but on crashes or restarts, replay (at most 3 days of events) everything - should work if the actions are idempotent.
3. Same as [1], but with an added proposal (that uses ideas from [2]) for the future. Merge the PR with webhook support (and use smee.io <> gosmee client temporarily, as we did over openspatial; or an automated way as described in [1]). In a different PR, add a “Replay GitHub deliveries daemon” that polls on github as an authenticated GitHub App and replays the events to Vira. Note: This daemon can be an app on its own instead of being part of Vira. Also Note: The primary difference between a webhook relay server (eg. gosmee) and the polling daemon (proposed here) is that we don’t need a publicly accessible endpoint for the later.

I prefer the third option, what do you think?

[srid]

I'm not a fan of polling, but let's leave this outside of the scope for this PR, and discuss it in a new issue. For now, I'll use smee for this PR.