web: the owner page reads the store directly instead of dispatching profile show #47

ownerPage in internal/httpd/web.go calls ListOrgsForUser, OrgMembers, ListReposForOwner, ActivityByDay/OrgActivityByDay and re-implements the CanRead filter, rather than dispatching profile show. Since !100 that command returns all of it, so the two now compute the same thing from the same store functions in two places — the drift risk the registry exists to prevent.

I left it alone deliberately when adding the command, and want the reason recorded rather than lost: the web's repo rows come from describeAll, which adds topics, license and last-commit date, and is shared with explore and search. Dispatching the profile command as-is would either drop those from the profile page or push web-specific presentation into the command payload. Neither is obviously right, so I did not pick one under time pressure.

Options:

• Add topics, license and updated to the command's repo rows, and let the web dispatch fully. The data is not web-specific — a native client would render topics too, and iOS currently omits them on the profile for exactly this reason.
• Have the handler dispatch for profile, membership and activity while keeping describeAll for row decoration. Removes most of the duplication, leaves the visible-repo filter in two places.
• Leave it, and accept that one page reads the store directly.

ActivityWindow was already collapsed to a single definition shared by both, so at least the reported year cannot differ.

Ref: krz/gitbay!100