CALL with omitted DEFAULT parameters can mis-handle DEFAULT expr() (e.g. DEFAULT func()) — wrong error or crash

Problem
When a stored procedure is invoked with fewer arguments than its formal parameters (i.e., parameters with DEFAULT are omitted), the server may:

incorrectly evaluate DEFAULT expressions during CALL argument binding (wrong routine resolution context), leading to errors such as ER_SP_DOES_NOT_EXIST even when the referenced stored function is valid; and/or
read past the end of the actual argument list while aligning formal parameters to actuals (sp_rcontext), potentially causing a crash.

Reduced Reproducer

CREATE DATABASE IF NOT EXISTS test_sp_call_default_func;

USE test_sp_call_default_func;

CREATE FUNCTION func(x INT DEFAULT 10) RETURNS INT

BEGIN

  RETURN x;

END;

CREATE OR REPLACE PROCEDURE p0 (x INT DEFAULT func())

BEGIN

  SELECT x AS x_val;

END;

CALL p0();

-- Expected: one row (e.g. x_val = 10)

-- Observed (before fix): ER_SP_DOES_NOT_EXIST or crash depending on build/path

Root Cause

execute_procedure incorrectly binds omitted parameters by reusing DEFAULT Item trees during caller-side binding. Defaults for omitted parameters should instead be applied via the stored-program default-parameter path (sp_instr_set_default_param) within the routine context.
Row_definition_list::adjust_formal_params_to_actual_params(THD*, List<Item>*) advances the actual-argument iterator beyond args->elements, leading to out-of-bounds access.

Fix / Tests

Code: sql/sp_head.cc, sql/sp_rcontext.cc
Test: mysql-test/main/sp_call_default_func_regression.test

Related
MDEV-38329 (named parameters for CALL) when creating this issue, I found this bug.
Link to PR: https://github.com/MariaDB/server/pull/4837