Decide how informational Security findings map to repository advisories #567

Finding

Spec finding S3 in PR #566: the required Security-audit severity rubric includes informational, but GitHub's repository advisory severity field cannot represent it.

Evidence

• skills/thirdshift-security-audit/SKILL.md includes an informational grade for a confirmed minimal-impact observation.
• GitHub's advisory update API accepts only critical, high, medium, low or null.
• Reproducing each finding #542 requires grading with the skill's own rubric and putting the severity in the advisory's severity field.
• cargo test --test security_run a_private_reproduction_accepts_the_rubrics_informational_severity -- --exact failed with invalid severity before the PR's fix and passes afterward. Private finding issues now retain the informational grade, notes and test.
• cargo test --test security_run an_informational_advisory_requires_a_day_shift_decision_without_an_invented_grade -- --exact verifies the current conservative public-repository behavior: fail with an explicit cause and leave the advisory unchanged, without inventing a different grade.

Decision for the Day shift

Decide how an informational reproduction should be represented on a public repository: whether it should remain a Security finding, and where its grade and reproduction evidence belong when the advisory field cannot carry that grade. The Spec does not settle this mismatch. Converting it to low or silently treating null as a reproduced severity would make a grading policy decision rather than implement the stated rubric, so that call is not the implement session's to make.

Raised by #566. Only needs-triage is applied so this decision pauses no Pass or work.