DHCPv6 client routes bypass netd/FRR — no full route integration

[troglobit]

Background

IPv4 DHCP client routes (via udhcpc) are funneled through netd → FRR staticd, so they
appear as static routes in show ip route. DHCPv6 client routes are not: odhcp6c.sh
installs them directly with ip -6 route add, completely bypassing netd and FRR.

In IPv6, the default route does not come from DHCPv6 itself (DHCPv6 has no gateway
option by design — RFC 8415). It comes from Router Advertisements (RA). odhcp6c
processes both DHCPv6 and RA in one daemon and surfaces RA-learned routes via the
$RA_ROUTES environment variable, which odhcp6c.sh then installs directly into the
kernel.

Problem

Because DHCPv6 routes bypass netd/FRR:

• They appear as kernel routes in show ip route instead of static.
• FRR/zebra has no knowledge of them, so they cannot be redistributed (e.g. into RIP orOSPF).
• They do not survive an FRR restart cleanly.
• The startup ordering fix (<!pid/netd> in the finit service stanza) that was applied
  to the DHCPv4 client (see commit 021ea798) has not yet been applied to
  dhcpv6-client.c either — that is a separate but related omission.

Expected behaviour

A DHCPv6 client default route (learned via RA and processed by odhcp6c) should appear
as a static route in show ip route, identical to how a DHCPv4 default route looks:

admin@infix:/> show ip route
   DESTINATION            PREF NEXT-HOP         PROTO     UPTIME
>* 0.0.0.0/0               5/0 192.168.122.1    static  00:00:02   ← DHCPv4
>* ::/0                    5/0 fe80::1           static  00:00:02   ← DHCPv6 (desired)

What needs to be done

1. Short-term / easy: apply the same <!pid/netd> startup ordering fix to
   src/confd/src/dhcpv6-client.c line 119 (mirrors commit 021ea798 for DHCPv4).

2. Full integration: rework odhcp6c.sh so that routes learned from DHCPv6/RA
   (including the RA-provided default route) are written into a netd config drop-in
   (e.g. /etc/netd/conf.d/dhcpv6-<ifname>.conf) and netd is signalled to reload,
   instead of calling ip -6 route add directly. This mirrors how udhcpc/DHCPv4
   feeds routes through netd today.

   The infrastructure is already in place: netd and the FRR backend both have full
   IPv6 route support (AF_INET6, ipv6 route FRR commands), and the YANG model
   (ietf-ipv6-unicast-routing, infix-routing.yang) supports IPv6 static routes
   with route-preference (distance).

References

• src/confd/src/dhcpv6-client.c — DHCPv6 client finit service generation
• src/confd/src/dhcp-client.c — DHCPv4 equivalent (already fixed)
• board/common/rootfs/usr/libexec/odhcp6c.sh — route installation script
• src/confd/src/routing.c — static route → netd config writer
• src/netd/src/config.c and frrconf_backend.c — netd IPv6 route handling