fix(radixtree_host_uri): add route id to service-fetch failure log

[AlinsRan]

Description

When a route with no hosts/host references a service that cannot be fetched, push_host_router logs:

failed to fetch service configuration by id: <service_id>

without the referencing route id, so an operator has no way to locate which route holds the dangling reference. The sibling filter_func error in the same file already logs route id: <id>; this aligns the service-fetch error to the same format.

This is not a routing-match bug. The route tree is rebuilt on demand (any request after a route/service version change triggers a full rebuild), and the rebuild iterates every route — so the error is emitted with the log context of whatever request triggered the rebuild, not the offending route. That is by design: the route with the missing service keeps matching as an only-uri route (missing service won't affect the route matching), traffic is unaffected. A dangling route→service reference only arises from user-side data: deleting a service with ?force=true (which bypasses the delete_checker) or writing to etcd directly, or a transient route/service watch ordering skew that self-heals. This PR only closes the diagnosability gap so the offending route can be found; it does not change matching behavior.

Fixes #13552

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change (log-text-only change; no behavior change — relying on existing coverage and CI)
• I have updated the documentation to reflect this change (N/A)
• I have verified that this change is backward compatible (log content only)