finding: duly_task.source carries no index, yet it is the filter column of every governed analytics measure — duly_duty.source is indexed #47

Noticed while implementing the analytics datasets (#9); filed rather than fixed because
src/objects/ was outside that card's file surface.

Observation

Every measure in all three datasets carries source IN ('catalog','assigned') — that is
the caliber rule, and it is deliberately on every measure with no exception list. So
duly_task.source is now a predicate on every analytics read in the product.

It is not indexed. duly_task.indexes (src/objects/task.object.ts):

{ name: 'duly_task_dispatch_identity', fields: ['duty', 'owner', 'period_key'], unique: 'organization' }
{ fields: ['owner', 'status'] }
{ fields: ['business_unit', 'due_date'] }
{ fields: ['due_date'] }
{ fields: ['last_update_at'] }
{ fields: ['assignment'] }

duly_duty does index its source ({ fields: ['source'] }), which is what makes
this look like an oversight rather than a decision: the two objects carry the same field,
for the same caliber reason, and only one of them indexes it.

Why it may still be the right shape

Worth stating so this is not treated as an automatic yes. source is a three-valued
select with a skewed distribution, so a standalone index on it is close to useless — a
scan of catalog rows is most of the table. The useful shapes are probably composite and
lead with something selective, e.g. ['business_unit', 'source'] or extending the
existing ['owner', 'status']. Which one depends on how #10's dashboard actually groups,
which does not exist yet.

Suggested handling

Leave until #10 lands and the real group-by patterns are visible, then pick a composite
index against measured queries rather than adding a standalone one now. Recording it so
the question is asked deliberately instead of being discovered as a slow board.