Allow remote dataset access

[dentiny]

Closes #12

This PR adds remote storage support, so data viewer could load lance dataset from not only local filesystem.
The core change is pretty simple actually, since lance dataset already support remote access natively.

Initial UI

After a successful load

Followup item

• Remote storage access is much slower than local access, I have a few optimizations on parallelism and cutting down IO requests in my own fork, will send out PR shortly: https://github.com/dentiny/lance-data-viewer

AI usage disclaimer:
GPT-5.5 helped me make the code change, I deployed my own fork to k8s and verified it worked

[gordonmurray]

Thanks for taking on remote dataset support. This addresses a real project need, but I’m requesting changes before merge.

There are two project-level requirements I need to settle as maintainer:

1. The existing local mounted-dataset workflow must remain available. This PR currently replaces the local dataset list with a remote URI form. Remote access should be additive rather than removing the primary local workflow.

2. The security model for arbitrary user-supplied URIs needs to be explicit. The viewer has no authentication, so allowing any browser user to submit s3://, filesystem, or other URIs could expose datasets accessible through the server’s credentials. Remote access needs a defined restriction/allowlist or a clearly trusted deployment model.

Please hold the implementation at this point while we agree those two design decisions. Once agreed, the revision should include:

• tests for the supported URI schemes and access policy;
• preservation of local dataset browsing;
• the remote API contract in docs/spec.md;
• the required [Unreleased] CHANGELOG.md entry referencing issue #12.

The capability is valuable, but the current UI regression and unrestricted URI access mean this is not safe to merge yet.

[dentiny]

Thanks for the mention!

On the security model, there are two separate boundaries:

• Access to the web application: Each Lance Data Viewer instance is deployed as a Kubernetes service within a single cluster and namespace. The Service is private (ClusterIP) and exposed through Cloudflare Tunnel. Cloudflare Access authenticates users through Google SSO and controls who may access that viewer’s hostname.
• Access to storage: Each viewer deployment has one dedicated storage identity, provided through a Kubernetes Secret or workload identity in its namespace. Lance uses these ambient credentials when opening datasets. The identity must be read-only and restricted to the approved buckets or prefixes.

All users admitted to one viewer share that deployment’s storage permissions. Different access domains should use separate viewer deployments, namespaces, credentials, and hostname access policies.

This is a trusted-deployment model rather than per-user authorization inside Lance Data Viewer. Deployments must not expose a credentialed viewer without external authentication.