Add caching for improved performance

[steveclarke]

Description

Cache frequently accessed data to reduce API calls and improve CLI responsiveness.

What to cache

• Workspace list (for name resolution)
• Space list per workspace
• Board list per space
• User list per workspace (for name resolution)
• Tag list per workspace

Cache strategy

• File-based cache in ~/.cache/superthread/ or XDG cache dir
• TTL-based expiration (e.g., 5 minutes for lists)
• Manual cache clear: suth cache clear
• Cache status: suth cache status
• Disable with --no-cache flag or config option

Benefits

• Faster name-to-ID resolution
• Reduced API rate limit usage
• Better offline-ish experience for read operations

[steveclarke]

Additional: Cache current user info

When running suth setup or suth users me, we should cache the current user's info:

• user_id - needed for resolving "me" in commands like suth cards assigned me
• display_name - for UI display ("Logged in as: Steve")

This avoids an extra API call every time "me" needs to be resolved to a user ID.

Could be stored in cache or state file since it's tied to the account.

[steveclarke]

Research: How CLI tools handle API performance

Looked at how gh, aws, kubectl, stripe, gcloud, and heroku CLIs handle this. The consensus is clear:

Cache metadata, not data.

What other tools do

Strategy	Who does it
Never cache resource data (cards, pods, instances)	Everyone
Cache discovery/schema metadata (resource types, member lists)	kubectl (6hr TTL), gh (opt-in --cache flag)
Credential caching with auto-refresh	Everyone
Name-based APIs that avoid resolution entirely	kubectl, heroku, gcloud

No tool caches mutable resource data by default. Financial data (Stripe) and infrastructure state (AWS) are explicitly never cached — stale data is more dangerous than slow data.

Where suth pays the performance tax

The expensive part isn't fetching cards or comments (one API call). It's name-to-ID resolution requiring extra calls:

• suth cards list -b "Sprint Board" -s "Engineering" → resolve space name → ID, then board name → ID (2 extra calls)
• {{@Stacey}} in a comment → fetch all workspace members to build the name map
• enrich_members on card lists → fetch members again for display names

Proposed approach

Short-TTL file cache for slow-changing lookup data only:

Data	TTL	Why
Workspace members	5 min	Needed for mentions + name resolution. New members are rare.
Board/list structure	5 min	Needed for name-to-ID resolution. Board columns change occasionally.
Space list	5 min	Changes very rarely.

Not cached: Cards, comments, search results, activity, or any mutable resource data.

Cache location: ~/.cache/superthread/ (following XDG conventions, same as kubectl's ~/.kube/cache/)

Cache controls:

suth cache clear              # Wipe everything (e.g., new member just added)
suth cache status             # Show what's cached and when it expires
--no-cache                    # Bypass cache for a single command

This follows the kubectl pattern — cache the "shape" of things (who are the members, what boards exist), not the things themselves.

Impact

Commands that resolve names (which is most of them when used with human-friendly names instead of IDs) would go from 2-4 API calls down to 1, since the resolution lookups would hit the local cache.