Reduce uint256 fields to smaller integer types for gas and storage savings

## Description

Currently most fields in structs use `uint256` even when their values will never approach 2²⁵⁶ - 1. This wastes storage slots (→ higher SLOAD/SSTORE gas) and bloats contract size.

## Proposal

Reduce integer size to smallest size that can hold maximum possible value, then reorder fields so they pack into 32-byte slots wherever possible.

Proposed changes:

- `Rail`
- `lockupPeriod` - `uint64` (timestamp / block number)
- `settledUpTo` - `uint64` (timestamp / block number)
- `endEpoch` - `uint64` (timestamp / block number)
- `commissionRateBps` - `uint16` (shares the same range as `COMMISSION_MAX_BPS`, i.e., 0 to 10,000)
- `Account`
- `lockupLastSettledAt` - `uint64` (timestamp / block number)
- `PayeeCommissionLimit`
- `maxbps` - `uint16` (0 to 10,000 limit)

Using `uint64` for timestamps or block numbers fields enables efficient storage packing, and reduce gas costs. It remains future proof, as 64 bits cover for over 584 billion years of Unix time and block numbers will never approach 2⁶⁴ in any realistic timeframe.

## Rationale
Using minimal width integers to tightly pack struct fields can significantly reduce storage gas costs[1].

## Next steps

1. Reorder struct fields so contiguous small types pack together.
2. Benchmark gas usage.

[1]: "Tight Variable Packing | Solidity Patterns" https://fravoll.github.io/solidity-patterns/tight_variable_packing.html