Async Job: Foreign Key Association for Project and Organization

Describe the current behavior
Async "Job" database model does not have project_id and organization_id FK relation

Describe the enhancement you'd like
Add these relations or use batch_job table for both the celery async job and other batch job status

Why is this enhancement needed?
From a maintainability perspective

Additional context

class Job(SQLModel, table=True):
    """Database model for tracking async jobs."""

    __tablename__ = "job"

    id: UUID = Field(
        default_factory=uuid4,
        primary_key=True,
        sa_column_kwargs={"comment": "Unique identifier for the job"},
    )
    task_id: str | None = Field(
        nullable=True,
        description="Celery task ID returned when job is queued.",
        sa_column_kwargs={"comment": "Celery task ID returned when job is queued"},
    )
    trace_id: str | None = Field(
        default=None,
        description="Tracing ID for correlating logs and traces.",
        sa_column_kwargs={"comment": "Tracing ID for correlating logs and traces"},
    )
    error_message: str | None = Field(
        default=None,
        description="Error details if the job fails.",
        sa_column_kwargs={"comment": "Error details if the job fails"},
    )
    status: JobStatus = Field(
        default=JobStatus.PENDING,
        description="Current state of the job.",
        sa_column_kwargs={
            "comment": "Current state of the job (PENDING, PROCESSING, SUCCESS, FAILED)"
        },
    )
    job_type: JobType = Field(
        description="Type of job being executed (e.g., response, ingestion).",
        sa_column_kwargs={
            "comment": "Type of job being executed (e.g., RESPONSE, LLM_API)"
        },
    )

    # Timestamps
    created_at: datetime = Field(
        default_factory=now,
        sa_column_kwargs={"comment": "Timestamp when the job was created"},
    )
    updated_at: datetime = Field(
        default_factory=now,
        sa_column_kwargs={"comment": "Timestamp when the job was last updated"},
    )

Empieza por localizar la definición de Job de SQLModel y los modelos o tablas existentes project, organization y batch_job. Compara si el trabajo asíncrono debería recibir ambas relaciones de clave foránea o compartir batch_job, y después inspecciona las convenciones relacionadas del esquema y de las migraciones. Se considera terminado cuando el diseño elegido mantiene las asociaciones necesarias sin duplicar los modelos de estado del trabajo.