Support multiple projects and repositories

[ivy]

Context

Currently Hive is implicitly single-project. It polls one GitHub Project board and works with repos found by convention at `~/src/github.com///`.

What might be needed

Multiple projects

• Multiple GitHub Project boards (e.g. one for `ivy/hive`, one for `ivy/dotfiles`, one for a work project)
• Each project may have different settings, polling intervals, or parallelism limits

Multiple repositories with different backends

• Some repos are developed directly on the host → systemd-run jail
• Some repos target containers → Podman jail
• Some repos might need the Ansible jail backend (Implement jail backend for local server replica via Ansible #8)
• The jail backend should be configurable per-repository, not globally

Relationship to existing design

• Core Principle Track agent performance metrics on pull requests (model, tokens, cost) #4 (Environment Parity) already anticipates this: "The jail backend is selected per-repo."
• The `.hive.toml` config file exists per-repo, which is a natural place for repo-specific settings
• The distinction matters: project = GitHub Project board (work source), repository = code target (work destination). One project may span multiple repos.

Scope

This is likely an incremental change rather than a big rewrite — the architecture already has the right seams. But it needs explicit support in the config, poll loop, and CLI.

[ivy]

Punting to icebox. The immediate need (multiple projects) is solved by running systemd instance units — one hive@<project>.service per project, each with its own --config. No hive code changes needed.

See: ivy/home-ops#13

Native multi-project support in the poll loop (single process, multiple boards) and per-repo .hive.toml remain valid future work if the instance unit approach doesn't scale.