CI: eliminate upload-sarif missing PR merge-object warning at exact-head scans

[seonghobae]

Exact-head AppGuardrail run 34637792706, job 103389923269, on #276 head 7973277a4c97db6eaa071ff2726187f6b33009f5 completed successfully, but github/codeql-action/upload-sarif emitted:

git call failed. Will calculate the base branch SHA on the server. Error: fatal: bad object b9f64dae92f9cbf16db5401dfdd0e3cede8641e7

The scanner checks out the exact contributor head with a depth-1 fetch, while GitHub supplies a PR merge-commit identity that is not present locally. upload-sarif falls back to server-side base resolution, so this does not currently block the gate, but the warning violates the no-warning CI contract and obscures whether local provenance is complete.

Acceptance:

• identify whether the missing object is the PR merge commit/base provenance expected by upload-sarif on pull_request runs;
• provide the minimum bounded checkout/fetch or explicit SARIF ref/base metadata needed so current-head upload does not attempt a missing Git object;
• preserve exact contributor-head analysis and persist-credentials: false;
• do not use stderr filtering, || true, shallow-warning suppression, or a broader fetch than necessary without evidence;
• add a reproducible hosted regression and verify the warning is absent while SARIF still binds to the exact contributor head.

The separate invalid AppGuardrail SARIF helpUri warnings are producer-owned at ContextualWisdomLab/appguardrail#1216 and should not be conflated with this LifeOS checkout/provenance warning.

[seonghobae]

Fresh exact-head reproduction from #247 Security run 34643498057, Trivy job 103408671264: scanner checkout verified 48087da1d1d5031374eacc12228d1a96f55359c0; upload-sarif then reported fatal: bad object b01389498606377f3d6d6d453a5cd6e383988a03, fell back to server-side base resolution, and uploaded successfully. This confirms #278 remains a persistent exact-head SARIF provenance warning rather than an AppGuardrail-only artifact. Keep the bounded-fetch / explicit-ref acceptance; no stderr suppression or broad history fetch.

[seonghobae]

Fresh owner lookup found an existing canonical central implementation owner: ContextualWisdomLab/.github#689 already tracks the organization Security Scan's upload-sarif fatal: bad object <synthetic merge sha> warning and explicitly requires materializing/verifying the PR synthetic merge object before SARIF upload. I added the #247 exact 48087da... / run 34643498057 / Trivy job 103408671264 reproduction there.

Keep #278 as the LifeOS downstream canary/consumer acceptance issue. Do not duplicate the central Security workflow repair here. The LifeOS-local AppGuardrail occurrence still needs to consume the same bounded provenance principle in its own workflow owner path if it remains after the central/root mechanism is clarified; no broad fetch, stderr suppression, or weakening of exact contributor-head analysis.

[seonghobae]

Local LifeOS repair lane is now Draft #279, stacked on #276 so it inherits the reviewed Node-24/exact-checkout foundation without copying it. Reality RED was exact ebedd2fc53a29070ce2067d42b53d5a297d9e605, run 34648222331 / job 103424010024: the new permanent contract failed only because Materialize AppGuardrail SARIF PR merge provenance did not exist. Minimum repair e3fabc8373f7d0672141fd6d47314a311b3027f4 adds a same-repository PR-only bounded fetch of refs/pull/<number>/merge at depth 1, validates the advertised github.sha, verifies the commit object, never checks out the merge commit, and preserves contributor-head SARIF ref/sha plus persist-credentials: false. Focused hosted verifier 34648499258 / 103424907302 is 3/3 GREEN. A broader package/format exact-head verifier is queued; do not treat this as runtime-warning closure until that passes and, after #276 reaches protected ancestry, a normal AppGuardrail PR run proves the handled fatal: bad object is absent.

[seonghobae]

LifeOS-local source repair is now complete on Draft #279. Reality RED was ebedd2fc53a29070ce2067d42b53d5a297d9e605, run 34648222331 / job 103424010024 (2/3 pass; only the new bounded SARIF-provenance contract failed). Minimum repair adds a same-repository PR-only depth-1 fetch of refs/pull/<n>/merge, verifies FETCH_HEAD == github.sha and the commit object, never checks out the merge commit, and preserves contributor-head SARIF ref/sha plus persist-credentials: false.

Exact source candidate e4a7ddcdf55a02ccbebd70f7654a529578b27db2, run 34649865068 / job 103429245032, completed SUCCESS: modified contract Prettier PASS, commercial-readiness 26 suites / 78 tests / 78 pass, typecheck PASS, build PASS, git diff --check PASS. Temporary verifier was retired by ordinary descendant 76e352ed063bcbf48be6061e2f0bf9edaa47ece7; #279 now changes only AppGuardrail plus the permanent contract.

Do not mark #278 complete yet. #279 is stacked on #276, so the persistent AppGuardrail pull_request: branches: [main] workflow has not produced the final normal-PR runtime canary. After #276 reaches protected ancestry, non-force restack/retarget #279 and require a normal AppGuardrail PR run where bounded merge provenance executes and the handled fatal: bad object is absent. Central Security Scan implementation remains .github#689.

[seonghobae]

#279 advanced to exact df0a74f0ccc639a0b01f35f3c6d909e9b7dd6ca8. The bounded merge-object materialization remains unchanged; fresh review found and repaired a separate false-positive in its source-verification helper: a named step could previously borrow required strings from a following unnamed run/uses sibling. Regression-only 169f18bc4b2ab94bf61a41b16cc5dbf60f3a8cb2 reproduced the leak locally under Node 22.16.0; df0a74f... now terminates the extracted step at any same-indentation YAML sequence sibling, with focused 3/3 local verification including preservation of deeper nested lists. Production AppGuardrail source did not change in this repair. #278 remains open until #276 reaches protected ancestry, #279 is non-force retargeted/restacked, and a normal main-targeting AppGuardrail PR run proves the original fatal: bad object warning is absent on the exact contributor head.

[seonghobae]

LifeOS-local #278 source lane has advanced through #279 Item 45. Exact current head 04ac6bed279ab668704fdec46084bc4bac4e9287 now makes same-repository PR SARIF upload fail closed on successful bounded merge-provenance materialization; hosted repair verifier 34746987123 / 103696614011 is GREEN. A current-head CodeRabbit review has since reported no new actionable Item 45 issue and independently confirmed the fail-closed control flow. Do not close #278 yet: the acceptance still requires #276 to reach protected ancestry, #279 to retarget/restack normally, and a normal main-target AppGuardrail canary proving the original handled fatal: bad object warning is absent while contributor-head SARIF binding remains intact.