[otp_ctrl] Verilator linting PartInvDefault breaks on overly long vector

When running Verilator (v4.210 and v5.029) lint through dvsim as invoked by:
```
$ util/dvsim/dvsim.py hw/top_darjeeling/lint/top_darjeeling_lint_cfgs.hjson --tool verilator --select-cfgs top_darjeeling
```
it chokes on the very wide `73536'h0` constant appearing here:

https://github.com/lowRISC/opentitan/blob/0bdd81e73bbc5479014d3e7729132a2b72ecb3ee/hw/top_darjeeling/ip_autogen/otp_ctrl/rtl/otp_ctrl_part_pkg.sv#L574-L578

with the following message: "Unsupported: Width of number exceeds implementation limit: 73536'h0 (IEEE 1800-2023 6.9.1)"

LRM 6.9.1 says that the maximum vector length is at least 2^16, and it would appear Verilator's is exactly this.

Verilator will be placated breaking the vector, such as this heavy-handed cleaving:
```verilog
78272'({
64'h4D104B5B0B3D8FDD,
4672'h0, // unallocated space
73536'({65536'h0, 8000'h0})
}),
```
but I wonder if this impairs readability, or matching up to otp's partitions.

Reproduce the failure with util/dvsim/dvsim.py and hw/top_darjeeling/lint/top_darjeeling_lint_cfgs.hjson using the top_darjeeling configuration. Inspect the generated otp_ctrl_part_pkg.sv code around lines 574-578 and verify the OTP partition mapping before choosing a Verilator-compatible representation. Done means the lint completes without the oversized-vector error while preserving the partition layout.

Written by the indexing model from the issue text.