fix(photo-loader): HELD batch barrier so create_batch no longer auto-sends via cron

[axisrow]

What

create_batch no longer drops items into the cron-visible PENDING queue. A new PhotoBatchStatus.HELD state holds them back until an explicit publish_batch moves them into PENDING, so the photo_due cron job cannot send a freshly-created batch without a deliberate publish step.

Closes #1173

Owner decision (semantic)

Отложка ≠ крон. Постинг по крону НЕ нужен — для отложенной отправки есть нативная отложка Telegram (schedule_send → статус SCHEDULED). Поэтому автоподхват cron'ом свежесозданного батча — дефект: «создать батч» НЕ должно означать «создать и отправить».

HELD is a distinct pre-publish barrier, not a reuse of SCHEDULED (SCHEDULED = already queued server-side on Telegram via schedule_send). The cron job claim_next_due_item only claims PENDING, so HELD items are invisible to it.

Root cause (before)

• PhotoTaskService.create_batch hardcoded status=PENDING on the batch and every item.
• claim_next_due_item picks status=PENDING AND (schedule_at IS NULL OR schedule_at <= now).
• Cron photo_due runs run_due every minute.
• Result: create_batch with at=now (e.g. agent-tool after fix(agent): resolve 'me'/'self' target in create_photo_batch/create_auto_upload #1167) → item immediately due → cron sends within a minute, no separate confirm.

Fix

Core barrier:

• New PhotoBatchStatus.HELD enum value (src/models.py).
• create_batch now stores batch + items as HELD (src/services/photo_task_service.py).
• claim_next_due_item only ever claimed PENDING — no change needed there; HELD is naturally invisible.
• New PhotoLoaderRepository.publish_batch(batch_id): atomically UPDATE SET status=pending WHERE status=held + flips the batch status (src/database/repositories/photo_loader.py).
• New PhotoTaskService.publish_batch(batch_id) thin wrapper (src/services/photo_task_service.py).

Consistency:

• cancel_item now accepts HELD (held items are cancellable).
• _sync_batch_status surfaces HELD when all items are held.
• jobs_read_model maps HELD to PENDING for the UI.

Surfaces (CLI / Web / Agent parity)

Surface	Create to HELD	Publish
Web	handle_photo_batch	POST /dialogs/photos/batches/{id}/publish + dashboard button
CLI	batch-create	photo-loader publish BATCH_ID
Agent	create_photo_batch	publish_photo_batch (confirmation gate)

Parity docs updated: docs/reference/parity.md, docs/reference/agent-tools.md, docs/reference/cli.md, docs/feature-map.md.

Tests (RED to GREEN)

• Service (the core regression): test_photo_task_create_batch_holds_until_publish — after create_batch, claim_next_due_item returns None and run_due processes 0; after publish_batch, the item becomes claimable and run_due sends it.
• Repository: test_publish_batch_makes_held_item_claimable, test_cancel_held_item.
• Lifecycle: test_sync_batch_all_held_stays_held.
• Agent: TestPublishPhotoBatch (confirmation gate + success), plus existing create-against-real-service tests now assert status == HELD.
• Web: test_photo_publish_batch_redirects_and_calls_service.
• CLI: test_publish_action.
• Permissions: tool_permissions_snapshot.json updated for publish_photo_batch (WRITE).

Verification

• ruff check src/ tests/ conftest.py — clean
• pytest targeted: 176 passed (32 repo+lifecycle, 65 agent+permissions, 21 CLI, 58 web/routes)