Do not route the internal (v3Internal) API through the external router

[evilgensec]

Problem

The /v3Internal API is an internal, service-to-service surface: its handlers (for example FileFetcherHttpHandlerInternal, AppStateHandler, PreferencesHttpHandlerInternal, AppLifecycleHttpHandlerInternal) do not call accessEnforcer.enforce(...) and rely on callers presenting an internal credential.

RouterPathLookup.getRoutingService only special-cases the public /v3 prefix and otherwise falls through to return APP_FABRIC_HTTP. The external NettyRouter therefore forwards /v3Internal/... requests to app-fabric for any authenticated external user, and the app-fabric pipeline does not require an internal credential for those paths. A low-privileged user can then call the internal API across namespaces — for example GET /v3Internal/location/<absolute-path> (FileFetcherHttpHandlerInternal → Locations.getLocationFromAbsolutePath) reads files rooted at the filesystem root, and the app-state / preferences / app-lifecycle internal handlers read or modify another namespace's data.

Internal callers do not use the external router for these paths — they go through service discovery (RemoteClient against Constants.Service.APP_FABRIC_HTTP, e.g. RemoteArtifactManager), so the router can stop routing /v3Internal without affecting internal traffic.

Change

RouterPathLookup returns DONT_ROUTE for any path whose first segment is v3Internal, mirroring the existing treatment of /v3/metadata-internals. RouterPathLookupTest is updated accordingly.

[gemini-code-assist]

Code Review

This pull request prevents external routing of internal APIs by returning DONT_ROUTE when the request path starts with the internal API version token, and updates the corresponding unit tests. Feedback suggests adding a defensive check for empty uriParts to avoid throwing an ArrayIndexOutOfBoundsException when routing empty paths.