fix: order simple routes before forwards that consume their class

[sini]

Problem

A simple den.lib.policy.route injecting into a home-env class (homeManager, or a custom hjem class) was silently dropped when the source class lived on a user aspect. Reported against a config whose hjemLinux → hjem policy never forwarded the user's class data.

Root cause

Home-env classes are not assembled in the pipeline pass where the route runs. home-env.nix:makeHomeEnv carries the class to its host output via userForward — a __complexForward (fromClass = homeManager, into host.class at home-manager.users.<n>). applyComplexRoute reads from the accumulating fold state, so any route producing into its fromClass must run first.

topoSortRoutes only registered __complexForward routes in its producerMap. A simple route producing into homeManager was invisible, so the consuming forward was never ordered after it — and when it ran first, the injected content was already gone.

This is why route → nixos (a host-terminal class) always worked while route → homeManager never did, regardless of scope, schema, or policy signature.

Fix

Treat every route as a producer in topoSortRoutes, so a complex forward consuming a class is ordered after any route producing into it. Self-references are excluded when computing dependencies (also removes a latent spurious self-dependency).

Verification

• New regression suite deadbugs/netadr-hjem-route.nix covers the user-scope-signature and user-self-provide (the reported config's exact shape) cases — both fail before, pass after.
• Full CI green: 837/837, including the #567 forward-ordering, route, and forward-* suites.

[sini]

Scope-generality verification

Confirmed the fix is not user-scope-specific. The producerMap/hasDeps keying is intoClass@sourceScopeId, so it orders a simple-route producer before any complex-forward consumer at whatever scope they share.

Added test-route-standalone-home-scope covering a standalone den.homes entity (the home resolving scope). Characterization by reverting only apply.nix:

Case	Resolving scope	Base	With fix
test-route-user-scope-usersig	host-attached user	❌	✅
test-route-user-scope-provide	host-attached user (self-provide)	❌	✅
test-route-standalone-home-scope	standalone home	✅	✅

The host-attached-user path delivers homeManager via makeHomeEnv's userForward — a __complexForward that reads the route-application fold state, so it's order-sensitive (the bug). The standalone-home path assembles via the home entity's own instantiate + extractSubtreeModules (direct class extraction, no complex-forward consumer), so it was already correct. The new test guards that scope.