feat: expose embed command_id in note API responses

[richardsolomou]

Description

Note.save() already returns the command_id from the embed_note background job it submits, but the note API routes were discarding this value. This PR surfaces the command_id in NoteResponse for both the create (POST /api/notes) and update (PUT /api/notes/{id}) endpoints.

This enables API consumers to poll GET /api/commands/jobs/{command_id} to know when note embedding has completed, which is useful for workflows that need to trigger downstream processing only after embeddings are ready.

Related Issue

N/A — This is a small enhancement to improve API observability for async embedding operations.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring (no functional changes)
• Performance improvement
• Test coverage improvement

How Has This Been Tested?

• Tested locally with Docker
• Tested locally with development setup
• Added new unit tests
• Existing tests pass (uv run pytest)
• Manual testing performed (describe below)

Test Details:
Added 4 new unit tests in tests/test_notes_api.py:

• test_create_note_returns_command_id — verifies POST returns the embed command_id
• test_create_note_command_id_none_when_no_content_embedding — verifies POST returns None when no embedding is triggered
• test_update_note_returns_command_id — verifies PUT returns the embed command_id
• test_update_note_command_id_none_when_no_embedding — verifies PUT returns None when no embedding is triggered

Full test suite passes (102/102 tests).

Design Alignment

Which design principles does this PR support?

• Privacy First
• Simplicity Over Features
• API-First Architecture
• Multi-Provider Flexibility
• Extensibility Through Standards
• Async-First for Performance

Explanation:
Exposes an already-available internal value through the REST API, enabling external consumers to track async embedding status. This aligns with API-First by making the note embedding lifecycle fully observable via the existing commands API, and with Async-First by giving callers the tools to coordinate with background processing.

Checklist

Code Quality

• My code follows PEP 8 style guidelines (Python)
• My code follows TypeScript best practices (Frontend)
• I have added type hints to my code (Python)
• I have added JSDoc comments where appropriate (TypeScript)
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings or errors

Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I ran linting: make ruff or ruff check . --fix
• I ran type checking: make lint or uv run python -m mypy .

Documentation

• I have updated the relevant documentation in /docs (if applicable)
• I have added/updated docstrings for new/modified functions
• I have updated the API documentation (if API changes were made)
• I have added comments to complex logic

Database Changes

• I have created migration scripts for any database schema changes (in /migrations)
• Migration includes both up and down scripts
• Migration has been tested locally

Breaking Changes

• This PR includes breaking changes
• I have documented the migration path for users
• I have updated MIGRATION.md (if applicable)

Screenshots (if applicable)

N/A — No UI changes.

Additional Context

This is a non-breaking, additive change. The new command_id field on NoteResponse is optional with a default of None, so existing clients are unaffected. The command_id will be None when the note has no content (and thus no embedding is triggered).

Pre-Submission Verification

• I have read CONTRIBUTING.md
• I have read DESIGN_PRINCIPLES.md
• This PR addresses an approved issue that was assigned to me
• I have not included unrelated changes in this PR
• My PR title follows conventional commits format (e.g., "feat: add user authentication")

[cubic-dev-ai]

No issues found across 2 files