fix(web): reuse project combobox in timeline popovers

docs/audience-scoping-backlog.md

@@ -19,6 +19,7 @@
 - `project.isImageGenConfigured`, `project.isDalleConfigured`: covered as authenticated low-risk configuration checks
 - `notification` self-service and manager boundaries: auth-covered across list, unread counts, reminders, deletes, broadcasts, task creation, and assignment boundaries
 - `assistant-tools` parity metadata: descriptions and parity assertions now match narrowed router audiences for resource overview, controller-only, self-service, and manager broadcast/task tools
+- `comment` architecture phase 1: generic free-form entity comments replaced by an explicit supported-entity registry, currently limited to `estimate` with controller/manager/admin access plus entity-aware checks on list/count/create/resolve/delete
 
 ### Dirty Files To Avoid Mixing Into This Batch
 
@@ -45,27 +46,9 @@ These files already have unrelated local edits. Audience parity work that would
 - the previously identified small hardening and tests/docs candidates have been completed, including the notification auth follow-up and assistant tool parity metadata cleanup
 - the remaining audience work is now architectural (`comment.ts`) or depends on broader policy decisions rather than another ready-made auth slice
 
-### Needs Architecture Or Policy Design
-
-These routes should not be batch-edited as “small safe slices” until a visibility model exists.
-
-#### `packages/api/src/router/comment.ts`
-
-- Current state: all core routes are `protectedProcedure`
-- Why this is not a small slice:
-  - reads and writes are keyed by generic `entityType` and `entityId`
-  - visibility depends on the backing entity, not on the comment record alone
-  - the current author/admin checks for resolve/delete are not enough to decide who may list or create comments on each entity class
-- Design work needed:
-  - define which entity types can host comments
-  - map each entity type to its audience source of truth
-  - centralize entity visibility checks before any comment read/write
-- Recommended path:
-  - treat comments as a separate architecture ticket, not part of the quick hardening batch
-
 ## Recommended Next Order
 
-1. `comment` architecture design ticket
+1. extend the comment entity registry only when a second real consumer exists and its backing audience is explicitly documented
 
 ## Slice Definition