[#9] Avoid frontend-core avatar barrel cycle

[mohagan9]

Description

Avoid importing UserAvatar through the @supertoolmake/frontend-core barrel from within frontend-core itself. The local import preserves the logged-in user's initials avatar, color, and tooltip behavior while removing the circular package boundary.

Bundle size comparison from yarn build in packages/client:

• Before: budibase-client.js 965.09 kB / 119.70 kB gzip; generated src chunks 390.67 kB / 104.58 kB gzip and 1,962.76 kB / 420.10 kB gzip.
• After: budibase-client.js 964.04 kB / 119.65 kB gzip; generated src chunks 389.49 kB / 104.52 kB gzip and 1,959.97 kB / 419.70 kB gzip.
• Difference: -1.05 kB / -0.05 kB gzip for the entry bundle; -1.18 kB / -0.06 kB gzip and -2.79 kB / -0.40 kB gzip for the generated chunks.
• The current Vite 8 build does not emit a UserAvatar-*.js chunk, so the issue-reported 417.27 kB chunk was not reproducible on this revision.

Addresses

• Remove/Replace UserAvatar #9

App Export

• Not applicable.

Screenshots

• Not applicable; no visual behavior changed.

Launchcontrol

Avoids a circular avatar component import so the logged-in user's initials avatar continues to work without unnecessarily importing the frontend-core package barrel.

[mohagan9]

Scope assessment for #160

The requested change is narrow in source scope, but potentially meaningful for the client bundle:

• date-fns is a direct dependency only of packages/bbui/package.json.
• Its only runtime use in this repository is packages/bbui/src/Form/Core/DatePicker/utils.ts, which imports the entire date-fns/locale namespace. That eager namespace import is the likely reason all locale data appears as a large bundle contributor.
• The date picker already uses dayjs for parsing, formatting, and date arithmetic; there is no broader date-fns date-operation migration required.

A complete removal should therefore be limited to:

1. Replacing the locale-start-day lookup in DatePicker/utils.ts.
2. Removing date-fns from packages/bbui/package.json.
3. Updating yarn.lock.
4. Adding focused coverage and measuring the production client bundle/visualizer before and after.

The main challenges are behavioral rather than architectural:

• Preserve the current navigator.languages handling, locale normalization, and Monday fallback.
• Preserve locale-specific first days of the week, including Sunday and Saturday regions, rather than assuming every locale starts on Monday.
• If Intl.Locale week-information APIs are used, account for browser/runtime support and invalid locale tags without allowing date-picker initialization to throw. A small static region mapping is the fallback, but it needs deliberate coverage.
• Confirm that the replacement does not change the date-picker and date-range-picker behavior, since both consume this helper.

Recommendation: treat this as a focused bbui bundle optimization, not a repository-wide date-library rewrite. The likely highest-value path is to remove the all-locales import, use a platform locale-week API where supported with a safe fallback, then verify representative locales (en-US, en-GB, and a Saturday-start locale) plus the client production bundle size. The issue's reported 17% should be validated against the current build rather than assumed to be entirely removable.