barrierModel arity mismatch: "Expected 4, but was 3" on documented-correct 3-column rows (python-all, javascript-all)

## Summary

CodeQL fatally errors when resolving `barrierModel` data extensions for `codeql/python-all` and `codeql/javascript-all`, on rows that exactly match the documented, correct format (and the format used identically by `sourceModel`/`sinkModel`, per github/codeql#21004).

## Repro

`.github/codeql/extensions/.../models/log-injection.yml`:

```yaml
extensions:
- addsTo:
pack: codeql/python-all
extensible: barrierModel
data:
- ["sciemo_one_client_base.safe_log", "Member[safe_log_value].ReturnValue", "log-injection"]
```

This is the exact format shown in the official docs (https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-python/, "Example: Taint barrier using the 'escape' function") and matches `barrierModel(type, path, kind)` as formally declared in the Ruby docs' reference section.

## Error

```
A fatal error occurred: A tuple in a data extension for the extensible predicate 'barrierModel' has an incorrect number of columns. Expected 4, but was 3.
```

## What we tried

Assuming a genuine 4-column requirement (the trailing column being `QlBuiltins::ExtensionId`, per `ApiGraphModelsExtensions.qll`), we tried supplying a literal 4th value ourselves. None satisfy validation — all fail with:

```
ERROR: In extension for codeql/python-all:barrierModel, row 1 is invalid. Found '"...", "...", "log-injection", ', which does not match the signature 'barrierModel(string type, string path, string kind, [int origin])'.
```

Tried for ``:
- `"manual"` (string, matching the `provenance` convention used elsewhere in MaD, e.g. sourceModel/sinkModel)
- `0` (int, repeated across rows)
- unique sequential ints per row (`1000`, `1001`, `1002`)

All fail identically. Per github/codeql#21004, `barrierModel`'s trailing param is `QlBuiltins::ExtensionId madId`, described as "the data extension row number" — auto-populated internally, never meant to be user-supplied (same as `sinkModel`/`sourceModel`, which only ever take 3 user columns). So there appears to be no valid literal a user can write to satisfy the 4-column requirement the arity check enforces.

## Versions tried (same failure on both)

- CLI 2.27.0 (codeql-bundle-v2.27.0, `python-all` 7.2.5 / `javascript-all` 2.10.1, via floating `codeql-action@v4`)
- CLI 2.26.4 (codeql-bundle-v2.26.4, `javascript-all`/`javascript-queries` 2.4.4, via `tools:` pinned explicitly to the 2.26.4 bundle asset)

Both hit the identical `Expected 4, but was 3` fatal error, and identical rejection of every literal 4th-column value tried.

## Why this looks like a real bug, not user error

This is the same failure *class* as github/codeql-action#2706 (`sourceModel` arity mismatch, C#, "Expected 10, but was 9"), which was triaged as a genuine bug and fixed upstream, not a documentation/config issue on the reporter's side.

## Impact

We currently work around this with `continue-on-error: true` on the analyze job, which means our repo has had **no functioning CodeQL security scanning at all** (all languages, not just the one with the custom model) since the analyze step fatally errors before any queries run.

## Ask

- Confirm whether `barrierModel` genuinely requires a 4th user-supplied column at these CLI versions, and if so, document the correct literal value for it.
- If it should only take 3 columns (matching the documented examples and `sourceModel`/`sinkModel`'s pattern), this looks like a packaging/version-skew bug between the compiled query pack and the `python-all`/`javascript-all` library pack.

Start by reproducing the failure from .github/codeql/extensions/.../models/log-injection.yml using the CLI 2.26.4 and 2.27.0 bundles. Read ApiGraphModelsExtensions.qll and compare its barrierModel signature with the documented three-column form and the python-all/javascript-all packs. Done means confirming the valid user-facing arity and identifying whether the fix belongs in the packs, CLI validation, or documentation.

Written by the indexing model from the issue text.