Detect falsy true arms in actions pseudo-ternaries

[terror]

Pre-submission checks

Please check these boxes:

• Mandatory: This PR corresponds to an issue (if not, please create
  one first).
• Having read the AI policy, I hereby disclose the use of an LLM or other
  AI coding assistant in the creation of this PR. PRs will not be rejected
  for using AI tools, but will be rejected for undisclosed use or
  use that violates the policy.

If a checkbox is not applicable, you can leave it unchecked.

Summary

Resolves #746

This diff adds an obfuscation audit check for GitHub Actions expressions that use the common condition && value || fallback pseudo-ternary pattern when value statically evaluates as falsy. In those cases, GitHub Actions short-circuit semantics return the fallback even when the condition is true, so expressions like foo && '' || 'bar' do not behave like ternaries.

The check reports the falsy true arm directly and handles chained || expressions so later pseudo-ternaries are not missed. It covers falsy constants such as empty strings, 0, false, null, and constant-foldable falsy expressions, while avoiding fine forms like !condition && 'value' || '' and non-falsy true arms.

n.b. This does not add an auto-fix yet. A reasonable follow-up would be to rewrite eligible patterns to the official case(...) form, for example converting condition && true_value || fallback into
case(condition, true_value, fallback). I'm open to getting this in here, but it may make the diff larger than ideal 🤔

Test Plan

cargo test -p zizmor

[woodruffw]

Thanks for opening this @terror. I'm curious what you think about doing this in a new audit (something like unsound-ternary?) -- it's arguably not obfuscation per se, but an expression footgun like the other unsound-* audits.

[terror]

Thanks for opening this @terror. I'm curious what you think about doing this in a new audit (something like unsound-ternary?) -- it's arguably not obfuscation per se, but an expression footgun like the other unsound-* audits.

I think that makes sense! I put it under obfuscation mostly because of the earlier issue discussion and because the existing audit already walks fenced expressions, but I agree that this is less about obfuscation and more about confusing semantics.

I'll look to scope this into a new unsound-ternary audit.

[woodruffw]

Thanks for working on this @terror! I did a quick skim of the docs, just a few small nitpicks. I'll do a full review of the audit's logic tomorrow as well.

[woodruffw]

Thanks a ton @terror!