Add lock schema compatibility gate for workflow lock files

[davidahmann]

Problem

Lock files were parsed without an explicit schema compatibility gate. Incompatible lock schema changes could be consumed silently and lead to ambiguous behavior instead of a deterministic fail-closed error.

What changed

• Added lock schema parsing/compatibility checks with explicit handling for legacy unversioned lock files.
• Added lock schema header emission (# gh-aw-lock-schema-version: 1) when writing lock output.
• Enforced schema validation in lock read paths used by resolve and stop-after handling.
• Added focused workflow tests for compatibility, resolve failure behavior, stop-after failure behavior, and header emission.

Validation

• go test ./pkg/workflow -run 'Test(WriteWorkflowOutput|ValidateLockSchemaCompatibility|ResolveWorkflowName_IncompatibleLockSchema|ProcessStopAfterConfiguration_FailsOnIncompatibleLockSchema|ExtractStopTimeFromLockFile)' ✅
• make agent-finish ❌ (environment/tooling mismatch while installing actionlint, compile errors in yaml.ParserError symbols)
• make fmt ✅
• go test ./pkg/workflow -short ❌ (baseline shell incompatibility in existing git patch tests: TestGitPatchFromHEADCommits, TestGitPatchPrefersBranchOverHEAD, TestGitPatchNoCommits due ${var@Q} bad substitution)

Refs #16360

[pelikhan]

Accidental close

[pelikhan]

I still don't understand why we need this.

[davidahmann]

You’re right, the current framing is too broad.

The need is only for gh-aw metadata compatibility (fields/comments we parse ourselves), not GitHub Actions YAML schema validation. I’ll narrow this to metadata-dependent paths and drop schema gating for plain workflow-name parsing.

If that still feels unnecessary, I’m happy to close this PR and revisit with a concrete migration breakage repro.