[Bug] headscale nodes approve-routes list-routes -i flag doesn't filter by node ID

[DueFaith]

Is this a support request?

• This is not a support request

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

After updating to the latest version of Headscale, there appears to be a regression in the CLI for route management commands that breaks existing automation and scripts.

When using the -i <node_id> flag with route listing commands, only the routes for the specified node should be returned, similar to how the previous headscale routes list -i <node_id> command worked.

The previous CLI command headscale routes list -i <node_id> -o json correctly filtered output to only show routes for the specified node ID.

Expected Behavior

The new command headscale nodes approve-routes list-routes -i <node_id> -o json ignores the -i flag entirely and returns route information for all nodes in the network, not just the specified node.

Steps To Reproduce

Have a Headscale instance with multiple nodes (subnet routers)
Run: headscale nodes approve-routes list-routes -i 12 -o json
The output contains route information for ALL nodes, not just node ID 12

Environment

- OS: MacOS Sequoia 15.7.2
- Headscale version: v0.27.0-debug
- Tailscale version: 1.80.2
- Deployment method: Podman container

Runtime environment

• Headscale is behind a (reverse) proxy
• Headscale runs in a container

Debug information

Impact on Automation
This issue specifically affects:

Ansible role for subnet router configuration
Scripts that need to verify specific node route configurations
Monitoring systems that check route status per node

The workaround of fetching all nodes and filtering client-side is not feasible for production environments with many nodes due to:

Performance overhead
Security concerns (exposing all node data)
Breaking existing automation that expects node-specific output

Note: This is a CLI-specific issue and does not appear to affect the actual routing functionality - routes work correctly once configured. The issue is purely with the management interface returning unfiltered results.