[Multica] GitHub ↔ Multica integration for external issue reporting

[dnovick]

Goal

Define and implement the integration strategy between GitHub Issues and Multica so that externally reported issues flow into the right system without losing either the GitHub public interface or Multica's orchestration capabilities.

Background

berean-bible-bots uses GitHub Issues as its public-facing issue tracker. Students and contributors report bugs and suggestions there. If we adopt Multica, we need to decide:

1. Should external reporters continue to use GitHub Issues (and we sync to Multica)?
2. Should external reporters use Multica directly (if it supports public issue intake)?
3. Should we use GitHub Issues only for triage, then move them to Multica for tracking?

See #582 for the full conversation context. Depends on #584 (Multica evaluation).

Options to Evaluate

Option A: GitHub → Multica sync (GitHub as intake, Multica as tracker)

• External users file issues on GitHub as today
• A webhook or scheduled sync creates corresponding Multica issues
• Multica is the canonical tracker; GitHub issues are archived/closed after import
• Pro: No change for external reporters; familiar interface
• Con: Two systems to maintain; sync complexity; potential for drift

Option B: Multica as public intake

• If Multica supports public issue reporting (unauthenticated or email-based), point external users there directly
• GitHub Issues becomes read-only or disabled
• Pro: Single system
• Con: Unknown if Multica supports this; changes user-facing interface

Option C: Hybrid — GitHub for bugs, Multica for project work

• External bugs and feature requests stay in GitHub Issues
• Internal project tasks (lessons, exercises, infrastructure) go to Multica
• Periodic manual triage moves high-priority GitHub issues into Multica
• Pro: Clean separation; no sync complexity
• Con: Two systems; triage burden

Action Items

• Assess Multica's public issue intake capabilities (as part of [Multica] Evaluate Multica as issue tracker and agent orchestration platform #584)
• Evaluate available GitHub ↔ Multica integration tools (webhooks, GitHub Actions, official connector)
• Prototype Option A (webhook sync) if Multica has a suitable API
• Choose and document the integration approach
• Implement chosen approach
• Update CONTRIBUTING.md and issue templates to reflect the new flow

Dependencies

• [Multica] Evaluate Multica as issue tracker and agent orchestration platform #584 (Multica evaluation)
• [Multica] Configure Multica project structure based on Mark's Linear setup #585 (Multica configuration)