Move database data explorers to dedicated pages

[thomhurst]

Problem

Database data explorers currently render below the resource-management table inside the generic Cloud Explorer. After selecting a table, database, or container, users must scroll past the resource list and inspector to reach the data workspace. The remaining area is cramped for records, document contents, editors, and SQL query results.

Affected deep-data experiences include:

• DynamoDB table items
• Cosmos DB containers and documents
• SQL database/table browsing and query results where supported

Proposed improvement

Move data exploration into a dedicated page or screen after selecting the relevant database resource. Keep resource management in the existing Cloud Explorer, then provide a clear Explore data action and direct route into a full-height workspace.

Possible route shape:

/cloud-explorer/:cloud/:service/:resourceId/data

Exact route design can follow existing router conventions.

Acceptance criteria

• Database resource lists remain focused on management operations.
• Supported database resources expose a clear Explore data action.
• Data explorers open in a dedicated, directly linkable route or screen.
• Dedicated view preserves cloud, service, resource, and container/table context.
• Breadcrumb or back navigation returns to the originating resource list.
• DynamoDB item browsing and Add record use the dedicated workspace.
• Cosmos container/document browsing, queries, create, and update use the dedicated workspace.
• SQL table browsing and query results use the dedicated workspace where available.
• Loading, empty, runtime-unavailable, and provider-error states remain explicit.
• Layout works without scrolling past the resource-management table and remains usable at narrower widths.
• Frontend continues using existing /api/* contracts; no direct cloud-runtime calls or custom provider protocols.
• pnpm lint, pnpm type-check, pnpm test, and pnpm build pass.

Notes

Prefer reusing DynamoDbTableExplorer, CosmosNoSqlPanel, and SQL explorer components rather than creating provider-specific duplicate flows.