[Tracking] v0.3.0: coherent public data-lake APIs for local and Azure storage

Nobody has claimed this yet.

## Goal

Build on the existing data-access, SQLite catalog, resolver, fetcher and publisher functionality to provide a supported public data-lake surface in Agora Workbench. A user should be able to configure local files or Azure Blob Storage, discover an artifact, and load it into code execution without a mandatory search service or embeddings endpoint.

Target: **v0.3.0**, following the v0.2.1 release. These issues do not request changes to the v0.2.1 release process. Implementations should rebase on that release and retain supported 0.2.x behavior unless a change is explicitly documented and migrated.

## Architecture and boundaries

- Keep reusable catalog/storage mechanisms in the public package, with a deliberate public namespace and structural extension interfaces.
- Reuse existing fetchers, publishers, resolvers and catalog code rather than create parallel implementations.
- Support local filesystem and Azure Blob Storage with explicit scan versus approved-manifest discovery modes.
- Use keyword search by default; make vector search and cloud integrations optional where dependency boundaries permit.
- Keep execution-session lifecycle and temporary outputs separate from durable catalog registration. Explicit promotion may publish a session output into the catalog.
- Applications supply identity and policy; catalog operations consistently enforce that policy.
- Prefer library composition and optional MCP exposure. A separately deployed HTTP service, arbitrary storage backends, and a new embedding model are not required.
- The package and its supported installation paths must depend only on publicly available distributions.

## Delivery sequence

1. Public contracts, identity/configuration, safe indexing and dependency boundaries.
2. A supported read-only vertical slice: local/Blob discovery -> resolution -> streaming into execution, with authorization and compatibility coverage.
3. Managed registration/upload/delete/promotion with concurrency and recovery guarantees.
4. Integrated documentation, deployment examples, migration guidance and release acceptance.

Read-only delivery is an implementation checkpoint, not a claim that managed writes are already complete. Mutations remain capability-gated until their acceptance criteria pass.

## Release acceptance

- One maintained implementation of generic catalog/storage behavior, with compatible old import paths and supported asset references.
- Local quickstart works without cloud credentials or an embeddings endpoint; installation requirements are documented accurately.
- Local and Blob examples exercise actual discovery-to-execution integration.
- Metadata visibility and file access follow the same authorization policy.
- Concurrent writes, interrupted operations and schema migration have explicit recovery behavior.
- Unit/integration coverage is included in each issue; the final acceptance issue covers cross-feature and real-service behavior.

## Work items

Implementation issues are linked below.

- [ ] #331 - Define the public catalog API, capability model and compatibility boundary
- [ ] #332 - Add stable artifact identities, revisions and reference migration
- [ ] #333 - Support versioned scan and approved-manifest catalogs on local and Blob storage
- [ ] #334 - Make catalog refresh and search semantics correct and deterministic
- [ ] #335 - Isolate optional cloud and vector dependencies for local catalog use
- [ ] #336 - Enforce caller-aware authorization across catalog and storage operations
- [ ] #337 - Wire catalog lifecycle and MCP discovery into code execution
- [ ] #338 - Implement recoverable managed upload, registration, deletion and promotion
- [ ] #339 - Define bounded streaming, path containment and transfer failure behavior
- [ ] #340 - Add public CLI, local quickstart and Azure deployment guidance
- [ ] #341 - Add cross-provider compatibility and v0.3.0 release acceptance coverage

Start with the linked implementation issues #331–#341 and the existing data-access, SQLite catalog, resolver, fetcher and publisher functionality named in this tracking issue. Done means the v0.3.0 release acceptance criteria are met, including local and Blob discovery-to-execution examples, authorization coverage, recovery behavior and documented installation requirements.

Written by the indexing model from the issue text.