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.

Bắt đầu bằng cách tái hiện lỗi từ .github/codeql/extensions/.../models/log-injection.yml bằng các bundle của CLI 2.26.4 và 2.27.0. Đọc ApiGraphModelsExtensions.qll và so sánh chữ ký barrierModel của nó với dạng ba cột được ghi trong tài liệu và các pack python-all/javascript-all. Hoàn tất có nghĩa là xác nhận số lượng đối số hợp lệ ở phía người dùng và xác định liệu bản sửa thuộc về các pack, việc kiểm tra tính hợp lệ của CLI hay tài liệu.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.