Bulk create: consider dropping the counter start / counter scale fields

Follow-up from @ankitgoswami on #863 ([comment](https://github.com/block/proto-fleet/pull/863#discussion_r3708579389)):

> Do we have a requirement for configurable counter start and scale? Or could the initial bulk-create flow simply generate `${prefix}${index + 1}` from only prefix and count? That would remove two fields and their state, sanitization, validation and the padding logic.

## Current state

The Multiple variant of the bulk-create forms exposes a **prefix + counter start + counter scale** triple, where scale is a zero-pad *width* (start `1` at scale `3` reads `001`), not a multiplier.

Two call sites share it:

- `client/src/protoFleet/features/fleetManagement/components/RackSettingsModal.tsx` — `rack-bulk-prefix`, `rack-bulk-count`, `rack-bulk-counter-start`, `rack-bulk-counter-scale`
- `BuildingSettingsModal` (bulk building create, currently on the #864 branch) — same shape

Both generate their labels through `client/src/protoFleet/utils/bulkNameSeries.ts` (`buildBulkNameSeries` / `formatBulkCounter`), which is the single source of truth for the on-screen preview and the `CreateRacks` / `CreateBuildings` payload.

## What dropping the two fields would remove

- Two `Input` fields and their state (`bulkCounterStartText`, `bulkCounterScaleText`) per form
- `bulkCounterStartError` / `bulkCounterScaleError` and the scale range check against `counterScaleMinimum`/`counterScaleMaximum` (1–6)
- Two of the three `digitsOnly` + `sanitize` call sites added in bd39312d8
- `formatBulkCounter` and `clampScale` in `bulkNameSeries.ts`; `buildBulkNameSeries` collapses to `` `${prefix}${i + 1}` ``
- The `counterStartInputMaxLength` / `counterScale*` imports from the bulk-rename constants

## Why it was built this way

Two reasons, both worth re-examining rather than treating as settled:

1. **It matches the comps.**
2. **It matches the existing bulk-rename convention** (`RenameOptionsModals`, `bulkRenamePreview.ts`), which already uses the same prefix + start + scale triple. The intent was that an operator who has used bulk rename already knows what the three fields do.

Neither is a hard requirement — there is no ticket asking for configurable start/scale.

## The real question

Zero-padding is the part with actual operational value: `R-001 … R-012` sorts lexicographically, `R-1 … R-12` does not. Racks and buildings get read in sorted lists all over the app. So the choice is probably not "keep all three or keep one", but:

- **A** — keep as is (three fields, matches comps and bulk rename)
- **B** — prefix + count only, no padding (`${prefix}${index + 1}`) — Ankit's proposal, simplest, but gives up sort-stable labels
- **C** — prefix + count only, padding derived from the count (a batch of 12 pads to 2, a batch of 500 pads to 3) — removes both fields and their validation while keeping labels sortable. Loses the ability to start at a number other than 1, which matters when adding a second batch to an existing row (`R-013` onward).

## Next step

Need @jmarrxyz's take on whether configurable start/scale is intentional in the comps or incidental, and whether C is an acceptable deviation. Deferred out of #863 rather than changed there.