Show a group's effective constraints, and where each comes from

[barborico]

Stacked on #621. Last PR in this series.

Urgency: 5 days; does not need to deploy alongside the rest of the stack
Expected review effort: MEDIUM

Motivation

Make it obvious what constraints apply to a group and why.

A group page lists the tags on it, which for a role is not the same question as what constrains it. A role's limits mostly arrive from the groups it is a member or owner of, and a tag applied to an app reaches every one of that app's groups. Someone asking why they cannot grant a year of access had to work that out from a tag list and a mental model of propagation.

What's Changing

A collapsed Effective constraints panel on the group detail page. Each row names a constraint in force, its coalesced value, and the tag it came from — with how that tag reached this group:

Origin shown as	Meaning
direct	the tag is on this group
via app Foo	inherited from the group's app
via membership in Foo	this role is a member of Foo, which carries the tag
via ownership of Foo	this role owns Foo, which carries the tag

That last distinction is the point: it separates a constraint a reader could lift by untagging this group from one they cannot.

The panel reads effective_constraints off the group detail the page already fetched, so it costs no request of its own, and it collapses by default since most readers are not asking.

The collapsed panel:

A directly applied constraint on a group:

Propagated constraints on a role:

Inherited constraints on an app group:

One piece of copy cleanup that came with it

Ten places rendered a time limit as Math.floor(seconds / 86400) + ' days'. That prints "0 days" for any limit under a day — which reads as no access at all, where the true answer is an hour — and "1 days" for exactly one day.

The panel formats the same values, so leaving this alone would have had a dialog and the panel above it disagree on the same page about the same group. All ten now use one timeLimitLabel helper, which renders <1 day, 1 day, 7 days.

The tag form's seconds-to-days conversion is untouched — that one populates an editable number field rather than prose, and rounding there is a separate question.

Validation of Changes

13 new frontend tests. Ten cover the panel: the empty case renders nothing, the summary count, a time limit folded into the constraint column, a boolean rendered without a redundant "— Yes", the tag link and origin text, singular/plural/sub-day formatting, an unrecognised origin echoed rather than mislabelled as direct, and a source entry with sources omitted (optional per the API contract). Three cover timeLimitLabel directly.

The panel's test stands in plain DOM for MUI, as the other component tests here do — this repo's style engine cannot be loaded under vitest — while forwarding Link's component/to props to the real router link, so the link assertion exercises rendered output rather than a mock.

Verified in a browser:

• A role that inherits a limit renders "Limit time of membership — 7 days" sourced "SOX-timelimit, via membership in Ledger-Admin" — the constraint is not on the role, and the panel says where it is from.
• The group carrying those tags directly renders both of its constraints with origin direct.
• The dialog on that same group now reads "limited to <1 day", matching the panel, where it previously read "limited to 0 days".

The guard at the call site is deliberate and measured, not redundant with the panel's own empty check: without it the wrapping grid item still contributes its own 24px of padding, adding a gap to every group that has no constraints — which is most of them.

958 backend / 79 frontend passing; ruff, ty, tsc, and prettier clean.

🤖 Generated with Claude Code