Improve hapi coverage

[jacknojo]

The false negative mentioned in https://github.com/github/codeql-team/issues/4623 (also reproduced on this PR as a regression test) had four separate breaks in the flow:

1. server.route(config) was ignored when config came from a helper.
2. Forwarding the whole request.query object was not treated as a source.
3. The custom endpoint registry's definition.handler.call(...) had no resolved target.
4. Arguments passed through createCached(...args) did not reach the wrapped function.

javascript/ql/lib/semmle/javascript/frameworks/Hapi.qll

• Recognizes Hapi route and ext calls independently of whether their handlers can immediately be resolved.
• Uses property-aware backtracking to find handler through helper return values.
• Treats request.query, request.params, and request.payload as sources when those entire objects are forwarded. It still prefers a specific child property when one is directly read.
• Adds a Hapi-specific flow step for custom route registries. It connects a function stored in a route definition's handler property with later calls through that same definition object.
• Uses object identity and parameter positions rather than reproduction-specific function or variable names.

javascript/ql/lib/semmle/javascript/dataflow/internal/FunctionWrapperSteps.qll

• CodeQL already recognized createCached(fn) as a forwarding wrapper, including the rest/spread pattern (...args) => fn(...args).
• It did not use that knowledge when the returned wrapper was later invoked.
• The new step backtracks an invoked wrapper to its concrete wrapped function and maps each call argument to the corresponding function parameter.
• This is generic higher-order-function support and is not specific to Hapi, caching, Sequelize, or this reproduction.