notify: optional default project on Service for one-arg ListThreads/ReadThread

[danmestas]

Summary

Service.ListThreads(ctx, project), Service.ReadThread(ctx, project, threadShort), and Service.MessageCount(ctx, project, threadShort) (added in #104, PR #111) take an explicit project argument because the notify repo can hold threads for multiple projects.

If a consumer is single-project, the project arg is repetitive. Adding an optional default project on ServiceConfig would let consumers carry it once at construction.

Proposal — pick one

Option A: optional default, methods stay multi-arg

type ServiceConfig struct {
    // ... existing fields ...
    Project string  // optional default project for thread methods
}

Existing methods accept "" for project and substitute s.config.Project if set. Returns an error if both are empty. No new methods.

Option B: separate one-arg variants

func (s *Service) ListThreadsDefault(ctx) ([]ThreadSummary, error)
func (s *Service) ReadThreadDefault(ctx, threadShort string) ([]Message, error)
func (s *Service) MessageCountDefault(ctx, threadShort string) (int, error)

Existing methods unchanged; new methods require ServiceConfig.Project.

Option A is more compact. Option B is more explicit. Either works.

Why this is ready-for-human not ready-for-agent

This is purely an ergonomic affordance — the explicit-project methods work today. Don't pick this up speculatively. Triggers worth waiting for:

• A consumer (bones, notify Expo app, future) actually asks for the one-arg shape.
• We notice we're calling svc.ListThreads(ctx, "fixedproject") repeatedly in our own code.

If neither happens within a few months, close as wontfix.

Out of scope

• Multi-project simultaneous mode.
• Changing the underlying free ListThreads(r, project) etc. functions.