Execute Markdown workflows without Git

[taras]

Story

As a workflow author, I want to start a workflow from any Markdown file,
including an untracked file or one outside a Git repository, so the file I name
is the file that executes while later resume remains deterministic.

Problem

The workflow slice delivered by #366 and #428 establishes a definition by
resolving HEAD and reading the document from that Git object. This exposes an
implementation mechanism as a user prerequisite:

• a file outside Git cannot run as a workflow;
• an untracked file cannot run; and
• a modified tracked file silently executes its older committed bytes.

The durable requirement is that every execution of a run uses one immutable
definition. It does not require the user to make a Git commit. The natural CLI
contract is that xmd workflow start <file> executes the bytes currently at
<file>.

Contract

workflow start retains an immutable, content-addressed snapshot of the exact
definition bytes it was given before authored execution begins. The initial
execution and every resume or replay use that retained snapshot.

Git is optional provenance. When the source belongs to a repository, its commit
and path may be recorded as non-authoritative metadata, but Git availability,
tracked status and a clean working tree do not decide whether the workflow can
start or resume.

The local source path locates input for start; it is not required to remain
present afterwards and is never substituted for the retained definition.

Acceptance

• A Markdown file outside any Git repository starts and completes as a workflow.
• An untracked Markdown file inside a repository starts and executes its current
  bytes.
• A modified tracked file executes its current working-tree bytes, never the
  older committed version.
• Changing, deleting or moving the source after start does not change replay
  or resume: the retained bytes execute.
• Reusing a run ID with the same definition snapshot and normalized props is
  compatible; changed definition bytes are an incompatible reuse.
• The definition snapshot is durable before authored execution begins. A
  persistence refusal executes no document and does not claim a runnable run.
• Resuming a retained snapshot does not require a Git checkout or invoke Git.
• Existing Git-object workflow runs remain readable and resumable under their
  existing definition version; the change does not reinterpret retained
  identity.
• No absolute host path becomes durable workflow identity.
• Ordinary xmd run behavior is unchanged.

Architecture work

Amend architecture.md and specs/workflow-workspace-spec.md so immutable
definition identity is a retained source snapshot rather than necessarily a Git
object. Settle explicitly:

• the versioned snapshot descriptor and compatibility with the existing Git
  descriptor;
• the logical source name used for diagnostics and future relative references,
  without making an absolute host path identity;
• whether the current single-root slice retains one document or a versioned
  bundle shape that can later contain dependencies; and
• the security boundary for retaining authored definition source, without
  altering the bytes that execute.

Dependencies and scope

• Add the xmd workflow start/resume filesystem vertical slice #366 / 🚀 Start and resume a workflow run from the CLI (#366 PR 2) #428 provide the existing foreground start/resume lifecycle being
  amended.
• Workflow storage remains the authority for retained definitions and run
  identity.
• Component dependency closure, repository effects and remote workflow hosts
  are not required for the initial single-root snapshot.