pika-orch-incus-cleanup-15

Three new methods are added to TestPikaciJobFixture:

• into_job_record_with_logs(host_log_path, guest_log_path) — consumes the fixture and builds a complete JobRecord, accepting explicit log paths so the PikaciRunStore::seed_fixture writer can pass real filesystem paths.
• into_event_job_record() — convenience wrapper that uses placeholder /tmp/*.log paths, suitable for lifecycle-event tests that never read log files.
• job_started_event(run_id) / job_finished_event(run_id) — produce the corresponding RunLifecycleEvent variants, boxing the record internally.

The import block gains RunLifecycleEvent under #[cfg(test)] to support the new return types.

// pikaci_store.rs — new imports
#[cfg(test)]
use pikaci::{
    JobRecord, PreparedOutputsRecord, RemoteLinuxVmExecutionRecord,
    RunLifecycleEvent, RunStatus,
};

Three methods mirror the job-level pattern:

• into_run_record(jobs) — consumes the fixture and fills every RunRecord field, accepting a pre-built Vec<JobRecord> for the jobs list. Fields that have no fixture counterpart (e.g. plan_path, all prepared_output_* transport fields) default to None or empty vecs.
• run_started_event(&self) — borrows the fixture (note: &self, not consuming) so callers can clone and reuse the fixture for both start and finish events.
• run_finished_event(self) — consumes the fixture, delegates to into_run_record(Vec::new()), and wraps the result in RunLifecycleEvent::RunFinished.

This means a test that needs both events can .clone() the fixture for the start event and then move it into the finish event.

Inside PikaciRunStore::seed_fixture, the old code manually destructured every field of TestPikaciJobFixture to build a JobRecord, and every field of TestPikaciRunFixture to build a RunRecord. Both blocks are replaced:

// Before (job)
jobs.push(JobRecord {
    id: job.id.clone(),
    description: job.description.clone(),
    // … 12 more fields …
});

// After
jobs.push(job.clone().into_job_record_with_logs(
    host_log_path.display().to_string(),
    guest_log_path.display().to_string(),
));

For the run record, the only field that cannot come from the fixture is prepared_outputs_path (computed from a local temp path), so it is set via mutation after construction:

let mut run = fixture.clone().into_run_record(jobs);
run.prepared_outputs_path = prepared_outputs_path
    .as_ref()
    .map(|(path, _)| path.display().to_string());

This drops ~40 lines of boilerplate from the production store-seeding path.

The forge.rs test module had its own fixture_job_event (15 lines) and fixture_run_event (30 lines) helpers plus the matching use imports. All are removed:

1. Imports narrowed — JobRecord, RunLifecycleEvent, and RunRecord are dropped from the use statement; only RunStatus remains because tests still reference it for struct-update expressions.
2. fixture_job_event deleted — 15-line function that built a JobRecord with placeholder fields.
3. fixture_run_event deleted — 30-line function that built a RunRecord with all transport fields set to None.
4. event_line updated — the helper still exists but now qualifies the type as pikaci::RunLifecycleEvent instead of relying on the removed import.

The structured_pikaci_events test previously constructed all four lifecycle events inline. Now it uses the fixture variable (a TestPikaciRunFixture already in scope) and TestPikaciJobFixture::passed_remote_linux:

let run_started = event_line(fixture.clone().run_started_event());
let job_started = event_line(
    TestPikaciJobFixture::passed_remote_linux("job-one", "job one")
        .job_started_event("pikaci-run-123"),
);
let job_finished = event_line(
    TestPikaciJobFixture::passed_remote_linux("job-one", "job one")
        .job_finished_event("pikaci-run-123"),
);
let run_finished = event_line(fixture.clone().run_finished_event());

The same pattern applies to the second integration test (structured_custom_lane), which only needs run_started and run_finished and drops from 13 lines to 2.

The structured_pikaci_failure_log_keeps_job_and_run_messages test verifies rendering of failed events. Instead of calling the deleted fixture_job_event(RunStatus::Failed, …) helper, it now uses Rust struct-update syntax:

TestPikaciJobFixture {
    status: RunStatus::Failed,
    exit_code: Some(1),
    message: Some("cargo test failed in crate pika_core".to_string()),
    ..TestPikaciJobFixture::passed_remote_linux("job-one", "job one")
}
.job_finished_event("pikaci-run-123")

This pattern keeps the deviation (failed status, exit code, message) visually prominent while inheriting all other defaults from the canonical constructor. The same approach is used for the TestPikaciRunFixture failure case, making the test both shorter and more intention-revealing.