Path filters never apply to the first push of a branch #171

ci.HasDiffBase is false when the old sha is empty or all zeros, which is what a hook sends for a new branch, so the filter fails open and every job runs (#169).

Failing open is right — a filter that skips a build when it cannot tell is worse than no filter. The problem is the case it lands on. The normal workflow here is branch, commit, open a merge request, merge; the first push of that branch is always a new branch, so a docs-only change runs the full e2e suite anyway.

Observed on !264, which touches nothing but .gitbay/wiki/** and still queued test, vuln and sonar despite all three carrying paths-ignore: [".gitbay/wiki/**"].

That leaves #169 helping only on a second push to an existing branch, which is not the shape most changes have.

Fix: for a new branch, diff against the merge base with the default branch rather than failing open. git merge-base <default> <new> gives a real base, and the changed-file list against it is what the branch actually proposes. Keep failing open when the merge base cannot be computed — unrelated histories, or a first commit in an empty repository.

Note the merge-request head path (QueueMRBuilds) passes an empty old sha deliberately and should keep failing open unless the same merge-base treatment is applied there too; decide that explicitly rather than by omission.

Ref #169.