fix: classify repository webhook hooks correctly

[pilipilisbot]

Summary

• Derive webhook hook target type from GitHub hook URL (/repos/... vs /orgs/...) before falling back to payload fields.
• Backfill existing webhook_hooks rows from github_api_url during queue/schema initialization, so already-stored bad rows are corrected after deploy.
• Keep org hook pings classified as organization hooks.
• Fix repository hook pings whose payload also includes organization.

Cause

Hook 692565163 is a repository hook (https://api.github.com/repos/gisce/github-agent-bridge/hooks/692565163), but the dashboard stored it as organization because repo-owned-by-org webhook payloads also include an organization object.

Validation

• PYTHONPATH=src /home/openclaw/.openclaw/workspace/github/github-agent-bridge/.venv/bin/python -m pytest tests/test_webhook.py -q (40 passed)

[giscebot]

The release failure was caused by a stale shallow checkout, not by this PR: while run 37429064394 was preparing, #246 advanced main, so the checkout no longer contained this run’s triggering SHA c8395f2.

Fix opened in #253. It checks out the exact workflow SHA with full history, skips stale runs without publishing, and rechecks main immediately before semantic release. The PR is mergeable and all CI jobs pass (dashboard, Python 3.11, Python 3.12).

This PR’s changes were included by the following successful release run in v0.71.2.