netfilter-match-modules: don't use inserted code as a printf format

[ispyisail]

Fixes the "compile from source" failure reported on the forum (t=18408), where make mediatek.filogic dies with:

src/statement.c:620:38: error: 's' undeclared (first use in this function)
620 | nft_print(octx, "%s"%s"", inv ? "!= " : "", stmt->weburl.match);

Root cause

insert_lines_at() in integrate_netfilter_modules.sh spliced snippet files into the real nftables sources with:

printf "$lines\n" >>.tmp.tmp

That passes the snippet as printf's format string, so the generated C depends on the shell's printf implementation. Two things get processed:

• %% → % — which is why the snippets were written with %%s to produce %s.
• \" — undefined in POSIX printf format processing, so implementations differ. dash and busybox ash preserve the backslash; bash and coreutils printf drop it.

So "%%s\"%%s\"" becomes "%s\"%s\"" (valid) under dash, but "%s"%s"" (broken) under bash — a string "%s", a bare %s token, then "". Hence 's' undeclared.

This is why it reproduces for some people and not others: it depends entirely on what /bin/sh is. Debian/Ubuntu point it at dash, so it builds; on a distro where /bin/sh is bash it fails. Nothing is wrong with the reporter's setup.

The blast radius matches the reported errors exactly — the only 4 spliced files containing \" are weburl (1 line), webmon (1), timerange (3), bandwidth (1), which is precisely the set of failing functions in the log, including timerange's three separate error lines.

The fix

• insert_lines_at() now uses printf '%s\n' "$lines", emitting the snippet literally instead of interpreting it.
• The snippets consequently drop the %% escaping they only carried to survive the old behaviour, so they now contain plain, valid C. \" stays as-is — it was always correct C, it was just being mangled in transit.

Only files spliced via action=insert were touched. Files handled by action=copy are unchanged, since a %% there is a genuine C printf escape.

Verification

Every one of the 101 spliced files was rendered through the old pipeline on a working (dash) system and through the new pipeline under both dash and bash, and compared:

files checked: 101 (each under dash AND bash)
RESULT: byte-identical to current dash output, in BOTH shells

So the generated sources are unchanged for everyone whose build works today, and now identical — rather than broken — for everyone whose /bin/sh is bash. The escape survey behind that claim: across all spliced files the only backslash sequence in use is \" (12 occurrences) and there are no lone %, so %% and \" were the complete set of printf-format dependencies.