refactor: migrate on-disk storage format to new terminology (project/activity)

[siculo]

Summary

Rename all on-disk storage structures to reflect the new terminology
introduced in issue #91 (Work → Project, Job → Activity).
This is implemented as a structured migration step on top of the
versioned storage mechanism introduced in issue #96.

Motivation

Issues #91–#93 rename terminology in Rust source, API surface and
plugin UI, but leave the on-disk format unchanged. Persisted data —
directory names, JSON field names inside stored files — still use the
old terms (task, job). Without this migration, the on-disk format
is inconsistent with the rest of the codebase after #91–#93 land.

Dependencies

• Implement versioned storage format with migration support #96 must be merged first. This issue implements the migration as
  a version step inside the migration runner introduced by Implement versioned storage format with migration support #96.
  Pre-migration data is treated as version 0; post-migration data is
  version 1 (or the next available version slot assigned by Implement versioned storage format with migration support #96).

Scope

On-disk directory / file names

• Project root directory: tasks/<id>/ → projects/<id>/
• Activity root directory (if any): jobs/<id>/ → activities/<id>/

JSON field names inside persisted files

• task_id → project_id in any stored JSON
• job_id → activity_id in any stored JSON
• Any other field or key that uses the old terms

Migration implementation

• Add a migration step in the runner (introduced by Implement versioned storage format with migration support #96) that:
  1. Reads existing data under the old paths/keys
  2. Writes it under the new paths/keys
  3. Removes the old paths/keys
• The migration must be idempotent: running it twice must be safe
• Pre-migration storage (no manifest or version 0) is automatically
  handled by the runner

Rust code

• Update all StorageStore implementations to read/write new paths
  and field names after the migration has run
• Remove any old-path fallback logic once the migration covers it

Documentation

• Update api/docs/ storage documentation to reflect the new
  on-disk layout

Acceptance criteria

• Existing data stored with old paths/keys is correctly migrated
  to new paths/keys on server startup
• Server operates normally after migration: all CRUD operations
  on projects and activities work correctly
• No occurrences of task or job remain in on-disk paths or
  JSON field names after migration (verified by integration test
  or inspection)
• Migration is idempotent (running startup twice does not corrupt
  data)
• Storage documentation reflects the new on-disk layout