fix(datafusion): reject unknown arguments for tag and index procedures

[jackylee-ch]

The unknown-argument check only ran for the six REST management procedures (management_parameters gated the guard), so a mistyped optional argument to a tag or index procedure was silently dropped.

create_tag(..., snapshotid => 5) tags the latest snapshot instead of snapshot 5, and create_global_index(..., index_typ => 'bitmap') builds the default btree — no error either time. A later rollback_to on that tag then restores the wrong data.

Java rejects a CALL argument that no parameter declares (ProcedureBase), which is why the guard was added (#837); it was just never extended past the management set. This declares the parameters of all eight tag/index procedures and runs the same check for every procedure through one reject_unknown_args helper. drop_global_index still routes partitions/dry_run to their existing "not supported yet" errors rather than reporting them unknown.

[JingsongLi]

Reviewed head 0a8b78ce. This fixes an end-to-end correctness issue: misspelled optional arguments previously caused create_tag to select the latest snapshot or create_global_index to choose its default type. The declared parameter sets match the arguments read by all eight tag/index handlers, and the existing management-procedure guard remains in place. I found no actionable code regression.

Validation: the new helper unit test passed; all 32 paimon-datafusion procedure integration tests passed; head CI is green. I also ran a temporary SQL-level regression test: CALL sys.create_tag(..., snapshotid => '1') and CALL sys.create_global_index(..., index_typ => 'bitmap') both returned the expected unknown-argument error, and the mistyped tag was not created. The temporary test was removed after verification. Please consider keeping that SQL-level regression in the PR so future changes cannot accidentally bypass the guard in execute_call.