jq: fix build broken by the CVE-2026-43895 backport

Since da15df26e6 ("jq: Fix CVE-2026-43895") "bitbake jq" fails with:

  cc1: fatal error: src/parser.c: No such file or directory

That patch is the only jq patch touching both src/parser.c and
src/parser.y. git orders the diff alphabetically, so patch(1) writes
parser.y after parser.c and the shipped pre-generated parser looks
outdated. Maintainer mode is disabled, so make runs the no-op '.y.c'
rule; having "rebuilt" the target it stops resolving it through VPATH and
looks for it in ${B}, where it does not exist.

Touch the generated bison/flex sources before configure so they are never
considered stale. This also covers any future patch touching src/parser.y
or src/lexer.l.

With maintainer mode enabled bison will no longer regenerate parser.c,
which is fine: the CVE patches update the .y and the generated .c
consistently.

Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Anuj Mittal <anuj.mittal@oss.qualcomm.com>

meta-oe/recipes-devtools/jq/jq_1.7.1.bb

@@ -47,6 +47,16 @@ PACKAGECONFIG[valgrind] = "--enable-valgrind,--disable-valgrind,valgrind"
 # Gets going with gcc-15 but See if it can be removed with next upgrade
 CFLAGS:append = " -std=gnu17"
 
+# The release tarball ships the bison/flex generated sources and maintainer
+# mode is disabled by default, so make(1) must never consider them outdated.
+# Patches touching src/parser.y (or src/lexer.l) make the shipped src/parser.c
+# look stale, which fires the "NOT building parser.c!" no-op rule. From then on
+# make looks for the file in ${B} instead of resolving it via VPATH and the
+# build fails with "cc1: fatal error: src/parser.c: No such file or directory".
+do_configure:prepend() {
+	touch ${S}/src/parser.c ${S}/src/parser.h ${S}/src/lexer.c ${S}/src/lexer.h
+}
+
 do_configure:append() {
 	sed -i -e "/^ac_cs_config=/ s:${WORKDIR}::g" ${B}/config.status
 }