exp: add non-mutating Jules readiness preflight

[mark-e-deyoung]

Purpose

Add the smallest missing readiness sensor for the existing hardened Jules dispatch path: determine whether an opaque approved target + approved task is currently dispatchable through exactly one Jules Source without creating a Jules session.

This is an experimental sensor only. It does not widen the target policy, add credentials, expose private target mappings, create sessions, dispatch work, poll results, or change acceptance authority.

Changes

• scripts/jules_preflight.py
  • reuses the existing hardened target/task/source resolvers from scripts/jules.py;
  • validates the opaque target policy, task registry entry, and unique Jules Source;
  • returns only sanitized readiness fields;
  • never calls the session-creation path.
• .github/workflows/jules-preflight.yml
  • protected workflow_dispatch using the existing jules-dispatch environment and actor gate;
  • receives only approved opaque target/task IDs;
  • supplies the existing secret-backed Jules credential and target policy to the read-only preflight;
  • does not create a provider session.
• tests/test_jules_preflight.py
  • verifies private repository/branch/source/prompt values cannot appear in the returned readiness object;
  • verifies the preflight path does not call the provider request/session function;
  • verifies an unapproved opaque target fails without disclosing configured private target metadata.
• .github/workflows/jules-preflight-tests.yml
  • secret-free PR tests for syntax and safety invariants.

Output contract

Successful preflight output is limited to:

• ready;
• opaque target;
• approved task;
• target/task policy state;
• jules_source: available-unique;
• session_created: false;
• authority_mutation: false.

It deliberately omits repository, branch, prompt, source ID, Jules session/provider metadata, activities, patches, and PR metadata.

Why this is separate from dispatch

The current control path can only discover some readiness failures while attempting a live session. That makes a provider mutation an unnecessarily expensive way to answer a configuration question. This preflight allows qualification/placement logic to distinguish READY from environment/policy/source blockers before spending a work-sample execution.

Non-goals

• no generic provider registry;
• no target enumeration;
• no arbitrary repository/branch input;
• no free-form prompt input;
• no status/polling workflow;
• no automatic dispatch after preflight;
• no secrets or private target metadata in public logs;
• no merge or deployment authority implied by this draft.