fix: Propagate queue errors, eliminate format!-based SQL construction

Two hardening changes to the dependent queue and orchestrator:

- dependent_queue::fail_job now propagates the rusqlite error via ?
  instead of silently falling back to 0 attempts when the job row is
  missing. A missing job is a real bug that should surface, not be
  masked by unwrap_or(0) which would cause infinite retries at the
  base backoff interval.

- orchestrator::enqueue_resource_events_for_entity_type replaces
  format!-based SQL ("SELECT {id_col} FROM {table}") with separate
  hardcoded queries per entity type. While the original values were
  not user-controlled, hardcoded SQL is clearer about intent and
  eliminates a class of injection risk entirely.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

src/core/dependent_queue.rs

@@ -117,14 +117,12 @@ pub fn complete_job(conn: &Connection, job_id: i64) -> Result<()> {
 pub fn fail_job(conn: &Connection, job_id: i64, error: &str) -> Result<()> {
     let now = now_ms();
 
-    // Get current attempts
-    let current_attempts: i32 = conn
-        .query_row(
-            "SELECT attempts FROM pending_dependent_fetches WHERE id = ?1",
-            rusqlite::params![job_id],
-            |row| row.get(0),
-        )
-        .unwrap_or(0);
+    // Get current attempts (propagate error if job no longer exists)
+    let current_attempts: i32 = conn.query_row(
+        "SELECT attempts FROM pending_dependent_fetches WHERE id = ?1",
+        rusqlite::params![job_id],
+        |row| row.get(0),
+    )?;
 
     let new_attempts = current_attempts + 1;
     let backoff_ms: i64 = (30_000i64 * (1i64 << (new_attempts - 1).min(4))).min(480_000);