feat: expose minimal library crate for programmatic API access

[jpoehnelt]

Summary

Expose a focused lib.rs so gws can be used as a Rust library dependency for programmatic access to Google Workspace APIs. This enables tools like CI integrations and custom automation to reuse the core logic without shelling out to the binary.

Related: #211, #376

Design Principles

1. Minimal surface area — only expose modules that are stable and useful outside the CLI
2. No CLI coupling — library consumers should not need clap, ratatui, or interactive OAuth flows
3. Facade over internals — provide a clean execute() function rather than exposing executor.rs internals

Proposed Public API

Modules to expose (pub mod)

Module	Purpose
discovery	RestDescription, RestMethod, RestResource — introspect Google APIs
error	GwsError — unified error type
config	config_dir() — resolve config directory
services	resolve_service(), SERVICES, select_scope() — service name to API mapping
validate	validate_api_identifier(), validate_gcp_location() — input safety
client	build_client(), send_with_retry() — HTTP with retry

Modules to keep internal (pub(crate))

Module	Why
auth, auth_commands	CLI-specific OAuth flow (browser redirect, token caching)
executor	Takes ArgMatches — CLI orchestration
helpers/*	Each helper parses ArgMatches directly
formatter	Presentation concern (JSON/CSV output)
setup, setup_tui	Interactive TUI
credential_store	Internal key storage detail

Programmatic execution facade (future)

For users who need to execute API methods programmatically:

pub async fn execute(
    service: &str,
    resource_path: &[&str],  // ["files", "list"]
    method: &str,            // "list", "get", "create"
    params: &HashMap<String, String>,
    body: Option<serde_json::Value>,
    auth: AuthToken,
) -> Result<serde_json::Value, GwsError>

This keeps CLI internals hidden while providing a clean interface. The AuthToken wrapper would accept a pre-obtained token string, decoupling from the CLI's OAuth flow.

Non-goals

• Exposing the TUI or interactive setup flows
• Guaranteeing API stability for internal modules
• Replacing the binary — the library is a complement, not a fork

Prior art

• PR feat: expose library crate for programmatic API access #376 by @geofflittle — good first attempt but exposes too many CLI-specific modules. The SSRF validation (validate_gcp_location) from that PR is independently valuable and should be extracted.
• Issue Expose a library crate (lib.rs) for programmatic Rust usage #211 — original feature request