docs(shotcut): clarify REPL vs one-shot auto-save

[Jah-yee]

Summary

Clarify the execution model for Shotcut's REPL vs one-shot usage in
shotcut/agent-harness/HARNESS.md, and document how the new
-s/--save flag affects auto-save behavior in one-shot mode.

This addresses follow-up concerns raised in
#15 about user
expectations for persistence when not using the repl subcommand.

Background

In #15 we introduced the -s/--save flag and an auto_save global
flag so that one-shot commands can automatically persist changes to the
project file after each mutation command.

As @jarrodcolburn pointed out, if the repl subcommand is not used,
many users might reasonably expect that commands will save changes by
default, making an explicit --save flag feel redundant.

@yuh-yang suggested addressing this more fundamentally via
HARNESS.md, which this PR does.

Changes

• Document the distinction between:
  • REPL mode: long-running process, shared in-memory session,
    no automatic saving.
  • One-shot mode: fresh process per invocation, in-memory changes
    only unless saved explicitly or via auto-save.
• Document how -s/--save enables auto-save for one-shot commands,
  including a concrete before/after example with timeline add-track.
• Add a short "Design note" acknowledging that:
  • Today, one-shot commands do not auto-save by default.
  • This is an intentional, explicit design that may be revisited
    (e.g. flipping the default to auto-save with a --no-save override)
    if it proves to better match common usage patterns.

Rationale

This PR does not change any behavior introduced in #15. Instead, it:

• Makes the execution and persistence model explicit in HARNESS.md.
• Documents the reasoning and trade-offs behind the current default.
• Provides a clear place to discuss potential future changes (such as
  default auto-save for one-shot with a --no-save opt-out).

This should help set expectations for users running one-shot commands,
and directly addresses the concerns raised in the discussion on #15.

[Jah-yee]

@yuh-yang

[jarrodcolburn]

Thanks for clarifying the REPL vs. one-shot behavior in the docs.

Following up on the auto-save discussion: to me, an explicit --no-save feels more like a --dry-run flag. In its current form, it’s a bit of a "silent discard"—the command "succeeds" but the results vanish. If we moved toward a "save-by-default" model for one-shot commands, we could mitigate the fear of accidental loss by adopting Shotcut's own backup pattern.

In recent versions (24.01+), the Shotcut GUI has a "Backup and Save" feature that creates timestamped copies (e.g., project-YYMMDD-HHMMSS.mlt) in a backups/ subfolder. If the CLI implemented a similar "backup-on-mutation" logic, we could safely default to auto-saving while giving users a versioned safety net to revert to.

Does the team have thoughts on aligning the CLI's persistence model with Shotcut's backup/autosave features rather than relying on explicit flags?

[yuh-yang]

I do agree with @jarrodcolburn 's opinion on the default behavior of auto-saving and dry-run. And yes, --no-save feels more like dry-run. Probably we typically only need: 1) default auto saving for one-line cmd, and 2) a must-have dry-run cmd