feat: make workflow deadline configurable - #468

Brings in 19 upstream commits: releases 2.11.1 and 2.11.2, including
NVIDIA#468 (configurable workflow deadline) and the 2.11.2 security fixes.

The only conflict was src/skillspector/state.py. Upstream NVIDIA#468 adds
SKILLSPECTOR_MAX_WORKFLOW_SECONDS -- the same name this fork added in
185d610 -- with different semantics: a 600 s default and only positive
finite overrides, where the fork used a 60 s default and <= 0 to lift
the ceiling. Upstream's version is taken whole, as the fork's DIVERGENCE
row for that file pre-registered ("drop this row if upstream adds a
same-named or equivalent override"). It is also more complete: it wires
the transitive budget in cli.py to the same setting.

Consequence handled downstream: a gate that sets the variable to "0"
would silently fall back to 600 s under upstream's rules. agent-skills
and book-to-skill now set 86400, which means the same under both.

tools/upstream_baseline.json moves the commit axis to 69dcdfb only; the
PR and issue axes are unchanged and not yet re-triaged.

AGENTS.md now says to verify on a venv outside OneDrive with
UV_LINK_MODE=copy: the in-repo .venv becomes a Files On-Demand
placeholder tree (os error 5 on reinstall), and hardlinked installs let
the cloud filter claim uv's cache (os error 396), leaving packages with
metadata but no module.

Verified that way, in two batches: 4009 passed, 39 skipped,
38 deselected, 4 xfailed, 0 failed. check_divergence: 12 upstream files
diverge, 12 registered.

Co-Authored-By: Claude Opus 5 <[email protected]>
Signed-off-by: SanHsien <[email protected]>

SKILLSPECTOR_MAX_WORKFLOW_SECONDS became upstream SkillSpector's own
variable in 2.11.1 (NVIDIA/SkillSpector#468), and upstream treats 0,
negatives and non-finite values as invalid: it logs a warning and falls
back to its 600-second default. Under upstream's rules the old "0" would
have silently meant 600 s -- the lifted ceiling this gate relies on, in
name only.

86400 means the same thing under upstream's semantics and under the
SanHsien fork's (where <= 0 used to lift the ceiling), so the gate is
correct whichever build is installed. SKILLSPECTOR_MAX_STATIC_SECONDS is
still fork-only and takes the same value.

Verified against the fork merged with upstream 2.11.2 (SanHsien/SkillSpector
75bd6f3): exit 0, no new findings across 25 skills, and no
invalid-value warning from the scanner.

Co-Authored-By: Claude Opus 5 <[email protected]>
Signed-off-by: SanHsien <[email protected]>

SKILLSPECTOR_MAX_WORKFLOW_SECONDS became upstream SkillSpector's own
variable in 2.11.1 (NVIDIA/SkillSpector#468), and upstream treats 0,
negatives and non-finite values as invalid: it logs a warning and falls
back to its 600-second default. This repository scans itself as one
bundle, so the graph-wide budget is the binding one; under upstream's
rules the old "0" would silently cap the scan at 600 s, and every file
left when it expires is recorded as runtime_limit with no findings.

86400 means the same under upstream's semantics and under the SanHsien
fork's (where <= 0 lifted the ceiling), so the gate is correct whichever
build requirements-security.txt pins. The pin itself is unchanged here.

Verified in CI-equivalent bytes: git-tracked files staged with CRLF
normalized back to LF per .gitattributes, scanned with the pinned
185d610 through tools/run_skillspector.py: 0 issues, 43 suppressed,
check_skillspector_report exit 0. (The local gate run against the
working tree is red for an unrelated reason -- this checkout's text
files are CRLF while the index and CI are LF, so evidence hashes differ.)

Co-Authored-By: Claude Opus 5 <[email protected]>
Signed-off-by: SanHsien <[email protected]>