SRA: quarter 0 is treated as a real quarter, the FIP starts at quarter 1

In the code, currently quarter 0 (ie [A - EPOCHS_PER_QUARTER, A)) handled as a real quarter:

Example, activation at epoch A.
Currently in code, during [A, A + POST_PERIOD) an admitted orchestrator can call `postVolume(0, x)`. From A + POST_PERIOD + VERIFICATION_WINDOW anyone can call `submitShares(0)`, and if something was posted it installs a map from those values, replacing the activation map. Until that crank runs, `removeOrchestrator` reverts with PendingShares(0), so no removal is possible in the first 10 days after activation.

In the FIP, the activation share map comes from the migration and the first posting is for quarter 1 at Start(2), and `RemoveOrchestrator` reverts only "from Start(Q+1) until quarter Q's SubmitShares has run" (§3.2), so removal is allowed at any point of quarter 1.
A quarter 0 value is also zero by the FIP's own rules: FPV counts only settlements on Filecoin Pay contracts admitted "effective for quarter Q" (§2.2), and a list installed before activation applies from quarter 1's first epoch, so no list is effective for any epoch before activation. The only correct posting for quarter 0 is 0, and the round can only be a no-op or a misreport.

Ask: start `nextQuarter` at 1 and reject q = 0 in `postVolume`, `correctVolume` and `submitShares`.

@wjmelements please review this before assigning to @LinZexiao ! thanks!

Start at nextQuarter and the postVolume, correctVolume, and submitShares entry points. Trace the quarter-zero path against the activation and FIP behavior described in the issue, then verify that quarter 1 is the first real quarter and q=0 is rejected in all three calls. Confirm removal is no longer blocked by pending quarter-zero shares.

Written by the indexing model from the issue text.