fix(ci): two checks that are wrong on a release PR

[0xmanhnv]

Two CI checks fail on a develop → main release PR for reasons that have
nothing to do with the release. Both were red on ui#345.

---

1. The palette gate flags a month of already-gated code

The gate I added in ui#340 turned Quality Checks red on ui#345:

This branch adds 5,000+ hardcoded Tailwind palette class(es):
      1 bg-red-100
      1 bg-orange-100
      ...

None of those lines are in that PR. The gate diffs against the PR's base:

PR type	base	"added lines" means
normal	develop	the lines this branch wrote
release	main	every line merged since the last tag

main is v0.3.0 from 2026-07-03 and develop is 140 commits ahead, so the gate
reported a month of other people's styling as if the release author had just
typed it. It would do that on every release, forever.

Why skipping is right here, not a cop-out. Every line in a release range
already passed this gate on its way into develop. Re-checking them at release
time is double jeopardy, and it is unactionable — the person cutting the release
cannot go fix a month of someone else's styling, so the only move available is
to override the check. A gate that always has to be overridden has stopped
meaning anything, and the next genuinely-red check on a release PR gets
overridden with it.

This is a different thing from the failure the script already guards against a
few lines below. That one — unresolvable base ref, exit 0 — hides a broken
gate, which is why ui#340 made it fail loudly in CI. This one declares a scope
out loud, on stdout, every time it applies.

Verified, all four paths

Case	Expected	Result
base origin/main, violation present in the range	skip	exit 0
base origin/develop, violation committed	fail	exit 1, names bg-gray-100 ×2, text-gray-500 ×2
base origin/develop, clean branch	pass	exit 0
CI=1, base cannot be resolved	fail loudly	exit 1

Row 2 is the one that matters: the gate still does its job on the PRs it was
built for. I checked it by committing a real violation, not by staging one —
git diff base...HEAD only sees commits, and my first attempt reported "no
added source lines" and would have let a broken gate through.

---

2. The release-candidate image is never scanned

docker-scan was gated on schedule || push to main, so it never ran on a PR
into main.

The symptom: code scanning compares a PR against the configurations present
on the base branch, and main expects a Trivy analysis from this job. With the
job skipped, every release PR reported 1 configuration present on refs/heads/main was not found and the Trivy check went red.

The part that actually matters: the container image was only ever scanned
after it reached main — which for this repo means after the tag that publishes
it. For a security product that is the wrong order. The job builds the image
itself (push: false, load: true) rather than pulling a published one, so
nothing stopped it running while the release is still reviewable. It just was
not asked to.

Costs one extra image build per release PR — a handful per year.

api has the identical condition and the same gap; it is not red there only
because main has no recorded Trivy analysis to compare against. Worth the same
change, in its own PR.