[API v3] Bootstrap the /api/v3/ entry point

[etj]

Why

Every v3 resource needs the same router, pagination, and field-selection mechanism.
Building that once first keeps the resource issues small.

What

• The /api/v3/ router and URL wiring.
• Shared base pieces: bounded pagination, a base viewset, the ?fields= mechanism, and the explicit-permissions requirement.
• No resource endpoints in this issue.

[etj]

Implementation notes:

• The one rule this issue exists to enforce: register every v3 route from exactly one file, with real imports -- never as an import side effect, and never from an AppConfig.ready() hook. v2 does both of those (a dozen api/urls.py files register onto a shared router just by being imported, and three apps mutate geonode.urls.urlpatterns from ready()), and the result is that include(router.urls) caches a snapshot list, so registration order silently decides what resolves -- v2 only fully works today because geonode_mapstore_client, a separate package, appends a third include() for the stragglers. Don't reproduce that.
• Verify routes by dumping the resolved URLconf (django.urls.get_resolver(), walked recursively), not by reading urls.py -- Django's routing has genuinely surprised us before on this branch.
• Pagination must be bounded. v2's DYNAMIC_REST['MAX_PAGE_SIZE'] is None -- uncapped, a client can request the whole catalogue in one page. v3's pagination class should set a real max_page_size (make it a settings value so it's tunable per deployment without a code change).
• permission_classes must be non-optional by construction, not just by convention -- add a test that walks every registered viewset and fails if any one leaves it unset. REST_FRAMEWORK has no DEFAULT_PERMISSION_CLASSES, so an omission means AllowAny.