src/backend/optimizer/plan/createplan.c

Add to src/test/regress/sql/rpr.sql near the FIRST offset tests (rpr_nav has columns id int, val int):

SET plan_cache_mode = force_generic_plan;
PREPARE test_first_offset(int8) AS
SELECT id, val, first_value(id) OVER w AS mf, count(*) OVER w AS cnt
FROM rpr_nav
WINDOW w AS (
ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A B+)
DEFINE A AS TRUE, B AS val = FIRST(val, $1)
);
EXECUTE test_first_offset(1);
DEALLOCATE test_first_offset;
RESET plan_cache_mode;

The `SET plan_cache_mode = force_generic_plan;
` is the load-bearing addition the original proposal omits: without it the planner const-folds $1 and executes line 2606 instead of 2608. With it, $1 remains a Param, extract_const_offset returns false, and line 2608 (context->firstNeedsEval = true) is driven.
Verified via gcov on the coverage build: 2608 count went from ##### to 1. Expected output for
EXECUTE(1) under the generic plan: rows (1,10,1,2),(2,20,,0),(3,30,3,2),(4,10,,0),(5,50,5,2),(6,10,,0) -- identical to the custom-plan result since the runtime offset value is the same;
capture it in rpr.out.

Line 2608 (context->firstNeedsEval = true) is genuinely reachable: it is the else-branch of `if (extract_const_offset(nav->offset_arg, 0, &offset))` in the RPR_NAV_FIRST case, taken when a simple FIRST(v, N) has a non-Const offset_arg.
I confirmed reachability empirically on a coverage-instrumented RPR build.
HOWEVER, the proposed test as written does NOT cover line 2608. I built+installed the RPR source into a temp datadir, ran the exact proposed
PREPARE/EXECUTE on a -DCOVERAGE build, stopped the server to flush gcda, and ran gcov: line 2606 (the if-branch) showed count 1 while line 2608 stayed ##### (uncovered).
Reason: by default PostgreSQL builds a CUSTOM plan for the first ~5 executions of a prepared statement, substituting the actual
EXECUTE argument for $1 and const-folding it to a Const, so extract_const_offset returns TRUE and the if-branch (2606) runs, not the else (2608).
To force the Param to survive planning as a Param I added `SET plan_cache_mode = force_generic_plan;
` before
EXECUTE and re-ran with cleared gcda: gcov then showed line 2608 count 1 and line 2606 ##### -- proving the else-branch fires only under a generic plan.
So the claim that $1 is a Param at planner time is only true with a generic plan;
the unqualified custom-plan path const-folds it.
The existing PREV($1)/compound PREV(FIRST(val,$1),$2) tests (rpr.sql:888,1260) very likely have the same custom-plan issue for their respective else-branches (2589/2643), but those lines were already covered by other const tests/paths and are out of scope here.