feat(jobs): declare run attributes on JobConfig

[GondekNP]

Follow-up to the provenance/coverage stack (#79–#82, now merged). Two commits on top of main.

What & why

Coverage (TargetDesign) matches on run attributes — what a run is about. Until now you set those with a set_attributes(run_hash, ...) call after dispatch, which meant reaching for the run's hash post-run and doing a separate tagging step. This lets you declare intent where it belongs — on the JobConfig:

JobConfig(
    source_path=SOURCE, config_path=config_path,
    attributes={"scenario": "historical", "treatment": "spinup"},
)

Those attributes are forwarded to the registry at registration time (right after register_run), in both the batch (SweepManager) and adaptive (strategies.py) dispatch paths. Coverage matches the moment run() returns — no post-run tagging.

Design notes:

• Intent, not config values. Attributes stay separate from config_parameters; the config never learns which Requirement it fulfills. Requirement matching was deliberately not wired into config parameters.
• YAML round-trip. attributes survives to_dict/from_dict/to_yaml, so YAML-defined jobs carry intent too (more than label gets today).
• set_attributes remains for amending a run after the fact.

Also here

• Tutorial target-designs.qmd reworked to declare attributes on the config instead of tagging after the run (freeze regenerated against the real jar).
• Minor: the tutorial no longer reaches into manager.job_set.jobs[0]; it iterates the SweepResult returned by run().

Tests

• test_jobs.py: attributes default/round-trip (dict + YAML), expander propagation (per-job copy, not shared ref).
• test_provenance_integration.py: real-jar test proving config-declared attributes persist through dispatch and satisfy a TargetDesign with zero tagging calls.
• Full jobs+sweep (279) and registry+provenance (207) suites pass. Version → 0.0.9.28.

🤖 Generated with Claude Code