Add GET /v1/goals/{goal_id}: fetch a single goal by id

[ZachL111]

Summary

Adds GET /v1/goals/{goal_id} to fetch a single goal by id.

Motivation

The goals API already lets a client update, delete, set progress on, and read the history and advice of a goal by its id, and lists goals via /v1/goals and /v1/goals/all. But there was no plain read of one goal by id. A client that wants to display or refresh a specific goal (for example after an edit, or when deep-linking to a goal) had to fetch the whole capped list and filter client-side.

Change

• database/goals.py: get_goal(uid, goal_id) returns the goal dict, or None if it does not exist. It mirrors the read update_goal already does (document(goal_id).get(), then _goal_dict to ensure the id is present).
• routers/goals.py: GET /v1/goals/{goal_id} returns the normalized goal, or 404 when the goal does not exist or belongs to another user (the lookup is scoped to the caller's own uid). It is declared after the static /v1/goals/* routes (/all, /suggest, /advice, /extract-progress) so those match first and are not captured as a goal_id.

The change is additive and does not touch existing routes.

Testing

• New tests/unit/test_goal_get_by_id.py: the endpoint returns the normalized goal and returns 404 when the goal is absent; the DB helper returns None for a missing document and fills id from the document id when present.
• Ran black, py_compile, the async blocker scan, the import-time side-effect scan, and the stub-pollution scan locally; all clean.
• Verified at the unit level (handler called directly, DB helper against a fake Firestore client). I did not run it against a live backend, since that needs Firestore credentials I do not have locally.

[Git-on-my-level]

Thanks for the focused addition — the endpoint and DB helper look straightforward, and the new unit coverage matches the intended 404/normalization behavior.

I do need to request one fix before this can merge: the committed app-client OpenAPI contract is stale. I reproduced the failing CI locally with:

cd backend
env -i PATH="$PATH" HOME="$HOME" OPENAPI_RUNNER_VENV="/tmp/omi-pr9386-review/.openapi-venv" \
  ./scripts/openapi_runner.sh scripts/export_openapi.py --surface app-client --check ../docs/api-reference/app-client-openapi.json

which reports:

OpenAPI contract check failed: ../docs/api-reference/app-client-openapi.json is stale; run backend/scripts/export_openapi.py --write ../docs/api-reference/app-client-openapi.json

Please regenerate and commit docs/api-reference/app-client-openapi.json for the new GET /v1/goals/{goal_id} route, then the contract check should be able to go green. I’m not seeing a security/supply-chain concern in the code itself; this is mainly a public API contract artifact issue on an authenticated goal read endpoint.

[ZachL111]

Done. Regenerated docs/api-reference/app-client-openapi.json with backend/scripts/export_openapi.py --surface app-client --write; the only change is the new GET /v1/goals/{goal_id} operation, and --surface app-client --check passes locally now. Pushed.

[kodjima33]

Backend read endpoint GET /v1/goals/{goal_id}; mirrors existing goal routes. Approve (feature, backend deploy is Nik's).

[Git-on-my-level]

Thanks for the follow-up here. I re-reviewed the current head after the OpenAPI/regenerated-client updates.

The previous docs/contract concern looks addressed: docs/api-reference/app-client-openapi.json now includes the new GET /v1/goals/{goal_id} operation, the generated TS/Swift clients include the matching helper, and the Public Developer API contract check is green. I also removed the stale docs-accuracy label.

Implementation-wise, the endpoint is a narrow additive authenticated read scoped through uid, returns 404 for absent/not-owned goals, and the new unit coverage exercises the router happy path, missing-goal behavior, and DB helper _goal_dict id/goal_id filling. I’m not seeing a security or supply-chain concern in the current diff.

Because this still touches an authenticated user-data API surface and there is an existing maintainer changes-requested review on the PR, I’m leaving this as a positive maintainer-ready signal rather than a formal approval. A human maintainer should do the final review/dismissal of the earlier requested-changes state if satisfied.

[ZachL111]

Thanks for the re-review and for clearing the docs-accuracy label. Agreed the OpenAPI regen resolved the contract check, and nothing else is outstanding from my side. Ready for a maintainer to dismiss the earlier changes-requested state whenever convenient.