"fix(store): create the task directory lazily, on first write

[tintinweb]

What

TaskStore created its backing directory (.pi/tasks/) eagerly in the constructor — even for sessions that never persist a task. This defers creation to the first write, so a session with no tasks leaves no empty .pi/tasks/ behind.

The directory still gets created exactly when needed: acquireLock() and save() already mkdir(..., { recursive: true }) on every mutation (from #27), so nothing else had to change. The constructor's mkdirSync was redundant.

Why it's safe

• Nothing reads or writes the backing directory between new TaskStore(...) and the first mutation. load()/list()/get() are existsSync-guarded (a missing dir just yields an empty list); every mutation routes through withLock → acquireLock/save, which create the dir.
• Verified end-to-end against the real filesystem: construct → no dir; read → still no dir; first create() → dir + file appear; reload → task persists.

Existing users

Purely subtractive. Task creation, listing, persistence, locking, and resume are unchanged, and existing .pi/tasks/ data is untouched. The only observable difference: a session that never creates a task no longer leaves an empty directory.

Relationship to #32

Extracted from #32 (thanks @jalaxy33) — this takes the lazy-creation half only. The auto-cleanup half (rmdir of .pi/tasks/ and .pi/ on session end) is intentionally not included. Closes #32.

Test plan

• npx tsc --noEmit — clean
• npx vitest run — all pass, including a new test asserting the dir is not created on construction but is created on first write
• npx biome check src/ test/ — clean