fix(Button): default htmlType to button to prevent accidental form submission

[munzzyy]

Why?

A native <button> without an explicit type defaults to type="submit". Button, IconButton, and SplitButton all accept an htmlType prop, but it was never defaulted, so it stayed undefined and the browser fell back to submit. Any of these rendered inside a <form> submits that form on click unless a caller remembers to pass htmlType="button". #1126 added the htmlType escape hatch and fixed a bunch of internal button usages, but left this specific default gap open, and the current test suite documents it directly (Button.test.tsx / IconButton.test.tsx both had a test literally titled "should not default to any type... thus behaving as type=submit").

Closes #1092.

How?

• Defaulted htmlType = 'button' in the destructured props of Button, IconButton, and SplitButton.
• Updated the existing "HTML types" test blocks in Button/IconButton: the old test asserted the buggy submit-by-default behavior, now it asserts the button does not submit by default and that type="button" is on the element. Added matching coverage to SplitButton.test.tsx, which had no test for the default case at all.
• Added a new test to each component confirming htmlType="submit" still submits the form when set explicitly.
• Checked every internal caller that relies on non-submit buttons (FileTabs, Select's InternalSelect, Table) — they already pass htmlType="button" explicitly, so this default doesn't change their behavior.
• Bumped the changeset from patch to minor per @ariser's review: this changes runtime behavior for any consumer who was relying on the old default-submit fallback, so it's not safe to treat as a patch. Called it out explicitly in the changeset body.

Tickets?

• #1092

Contribution checklist?

• You've done enough research before writing
• You have reviewed the PR
• The commit messages are detailed
• The build command runs locally
• Assets or static content are linked and stored in the project
• For documentation, guides or references, you've tested the commands

Security checklist?

• All user inputs are validated and sanitized
• No usage of dangerouslySetInnerHTML
• Sensitive data has been identified and is being protected properly
• Build output contains no secrets or API keys

Preview?

N/A — behavior-only change (default prop value), no visual change. yarn test (full suite, 505 tests) and yarn typecheck both pass locally.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8fade1c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clickhouse/click-ui	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ariser]

1. SplitButton has this prop as well https://github.com/ClickHouse/click-ui/blob/main/src/components/SplitButton/SplitButton.types.ts#L38
2. This is a breaking change, we should not just merge it without a migration plan for consumers. We can't assume all use cases that expect default submit behavior are covered by tests. This can break silently.

[ariser]

definitely not a patch

[munzzyy]

Good catches, both fixed:

1. Added the same default to SplitButton and covered it with tests (default-is-button, explicit button, explicit submit) — it had no coverage for the default case at all before this.
2. Bumped the changeset to minor and called out plainly that this changes runtime behavior for anyone relying on the old default-submit fallback, with the workaround (htmlType="submit") spelled out.

Full suite (505 tests) and typecheck both pass locally.