docs(schema): document recommendations cloud_account_id filter semantics + add tests

[cristim]

Gap

The recommendations (and related history-state) tables now carry a nullable cloud_account_id column for per-account attribution (spec specs/multi-account-execution/data-model.md, "Existing Table Modifications"). The filtering logic for account_ids query params and the backward-compatibility semantics for legacy NULL rows are implemented but undocumented — neither in code comments at the handler/store layer nor in an ADR.

This is a documentation-only gap, but a load-bearing one: a future maintainer modifying the filter logic could easily break one of the four implicit cases below without a test or comment to flag it.

Spec sections: specs/multi-account-execution/acceptance.md D-1, D-3, D-4; specs/multi-account-execution/data-model.md "Existing Table Modifications".

Acceptance criteria

• Document the four filter cases inline (handler comment + store-layer comment) with the contract:

  account_ids param	cloud_account_id row	Result
  absent	any (incl. NULL)	row included
  non-empty	NULL	row excluded (legacy rows are not "in any account")
  non-empty	matches one of the IDs	row included
  non-empty	doesn't match	row excluded
  non-empty, contains a disabled account's ID	matches	row excluded (disabled accounts' recs aren't surfaced)

• Add table-driven tests in internal/api/handler_recommendations_test.go covering each row above.

• Add the same documentation table to internal/config/store_postgres.go near the ListRecommendations filter logic.

• Validate account_ids format at handler boundary: each entry must be a valid UUID; reject the whole request with 400 if any entry is malformed.

Out of scope

• Backfilling pre-migration NULL rows to a default account — backward-compat-by-design per the spec.
• Changing the filter semantics — only documenting and testing what already exists.

References

• Spec: specs/multi-account-execution/acceptance.md scenarios D-1, D-3, D-4; specs/multi-account-execution/data-model.md
• Handler: internal/api/handler_recommendations.go (account_ids filter parse)
• Store: internal/config/store_postgres.go (ListRecommendations filter logic)
• Surfaced via the gap analysis on PR docs(specs): multi-account execution draft spec #89.

[cristim]

Closing — PR #236 (merged) delivered the documentation comments at both code sites and added TestGetRecommendations_AccountIDFilter with 6 subtests covering all five filter cases from this issue's acceptance criteria. The PR was missing a closes #211 trailer so this didn't auto-close.