feat(BarChart): expose bar size and gap props

[osk02]

Summary

Recharts' BarChart and Bar components accept four standard props for controlling bar width and spacing — maxBarSize, barSize, barCategoryGap, and barGap. The Force UI wrapper currently swallows all of them, so consumers cannot cap or shrink bar widths without forking the wrapper.

This PR forwards them through:

• barCategoryGap and barGap go onto the inner <BarChart>
• maxBarSize and barSize go onto each <Bar>

All four props are optional. When unset, Recharts' default sizing applies, so existing behavior is preserved for current consumers.

Why

When using <BarChart> for charts with a small number of data points, the default sizing fills the full band and produces visually heavy bars. There is no current API to cap or set bar width without re-implementing the wrapper.

Changes

• Added maxBarSize?: number (forwarded to each <Bar>)
• Added barSize?: number | string (forwarded to each <Bar>)
• Added barCategoryGap?: number | string (forwarded to inner <BarChart>)
• Added barGap?: number | string (forwarded to inner <BarChart>)
• JSDoc for each new prop, with links to the relevant Recharts API page

Testing

Verified locally by patching the compiled dist/components/bar-chart/bar-chart.es.js in a consuming project and passing maxBarSize={ 32 } — bars correctly cap at 32px wide regardless of chart width.

• Storybook smoke check (existing stories should render unchanged with no new props passed)
• Verify a story or test with maxBarSize set produces visually thinner bars

Backwards compatibility

All new props are optional and default to undefined, which Recharts treats as "use auto sizing". No existing consumers need to change anything.

[github-actions]

What: Consider validating the types for barSize, barCategoryGap, and barGap. Currently, they accept a number or a string but lack type enforcement that could prevent unexpected values.

Why: Validating prop types helps to catch bugs early and maintain consistent usage of the props, which is important for debugging and ensuring the component behaves as expected. Incorrect values can lead to runtime issues or unexpected styling in the rendered chart.

How: Implement PropTypes or TypeScript runtime checks to validate incoming values. For example, if using TypeScript, you could create a custom type guard that ensures that values are strictly either numbers or valid percentage strings before passing them to the Recharts components.

[osk02]

Matches the existing pattern in this file — activeBar, xAxisFontColor, borderRadius, and other typed props rely on the TypeScript signature for compile-time validation, no runtime PropTypes. The ?: number | string types here are sufficient and stay consistent with the rest of the component.

[github-actions]

What: Ensure props related to styling don't overwrite important CSS properties set by Recharts. Double-check if there's a possibility of conflicting with existing styling if users have set custom styles on the Bar or BarChart components.

Why: Inconsistent styles can result in visual bugs or user dissatisfaction. By being cautious about style overrides, you ensure better integration with users' custom designs.

How: You might want to document the behavior when users custom styles and clarify how the new props might affect them. It could also be beneficial to include safeguards or fallbacks in case of invalid values.

[osk02]

No CSS is involved here — these props are forwarded to Recharts which translates them into SVG attributes (rect width/height) on the bar elements. There are no styles being overridden so there is nothing for a custom user style to conflict with.

[github-actions]

What: Document the implications of setting a maxBarSize or barSize when combined with barCategoryGap and barGap. Provide improvement in your documentation for future developers.

Why: Understanding how different props interact with each other is crucial for developers to use the component correctly without unintended side effects. Missing context can lead to inappropriate usage and confusion.

How: Add examples in your JSDoc comments showing how these props might interact, and reference potential edge cases developers should be aware of.

[osk02]

Each prop is documented with a @see link to the corresponding Recharts API page where the interaction is described. Duplicating that documentation here would re-document Recharts behavior — the existing pattern in this file (e.g., activeBar at line 113-116) does the same: short JSDoc + @see link.

[osk02]

Closing this PR as it is affected, and I have cleared the worktree previously so there is no local copy for the branch.
New PR: #454