hermes - 💡(How to fix) Fix feat(kanban): max_in_progress should be enforced across all gateways/profiles sharing the same kanban.db

Problem

max_in_progress is a per-gateway voluntary parameter. When multiple gateways/profiles share the same kanban.db, each gateway can bypass the others' concurrency limits.

Root Cause

In kanban_db.py:4816-4825, the guard is:

if max_in_progress is not None and ready_rows:
    running_count = self._count_running_tasks()
    remaining = max_in_progress - running_count

If a gateway does not set max_in_progress (defaults to None), the guard is skipped entirely — that gateway can claim any number of tasks regardless of what other gateways have configured.

Example Scenario

• Profile A (annotator): runs a local LLM, sets max_in_progress: 1
• Profile B (test-engineer): sets no max_in_progress (or a higher value)
• Both share the same kanban.db
• Profile B claims 5 tasks simultaneously → all 5 workers hit Profile A's local LLM → timeouts, task pileup, serial execution degraded

Suggested Fixes

1. Global max_in_progress store: Store max_in_progress in a metadata table in kanban.db itself instead of per-gateway config, making it a database-level constraint.
2. SQL-level cap: Use UPDATE ... WHERE status='ready' ... LIMIT <remaining> to atomically limit claims per dispatch cycle.
3. Config option: Add a global kanban.enforce_max_in_progress: true to config.yaml that applies to all gateways.

Reproduction

1. Set up two profiles sharing kanban.db
2. Configure max_in_progress: 1 in one profile's config.yaml, leave the other unset
3. Create enough tasks with matching skills
4. Start both gateways
5. Observe: tasks claimed in batches from the unconstrained gateway, bypassing the other's limit

Environment

• Hermes version: latest (main branch)
• kanban.db: SQLite shared across profiles
• OS: Linux