t27f: frame shards as a generic spec, frame_shard.t27 #10385

PR #10384 made token_floor render in 48 shards, but the partition and the TF_SHARD/TF_SHARDS reader live inside specs/t27f/token_floor.t27. Every other reel renderer would copy them, and token_floor.t27 is being rewritten (portrait and landscape) by its owner in PR #10378.

Boundary

• In scope: new specs/t27f/frame_shard.t27, the same partition with the reel length as a parameter, plus env_first(frames) / env_end(frames) for a renderer's main, and its seal.
• Out of scope: token_floor.t27 itself. Its owner switches it to use t27f::frame_shard in the render(wide) rewrite. Also out of scope: frame_cache.t27, which is already generic, and any CI job.

User Scenarios

• A reel renderer's author adds use t27f::frame_shard; and three lines in main, and the lab renders the reel in N parallel shards whose concatenation is the one-process output.
• Someone runs the binary with no TF_SHARD/TF_SHARDS set, or with an invalid pair, and gets the whole reel.

Requirements

• Shard k of n covers [shard_a(k, n, F), shard_b(k, n, F)), and the shards of one n tile [0, F) in order for any F.
• An n outside 1..F or a k outside 0..n-1 means the whole reel.
• getenv is reached only through env_first/env_end, so the tests never need libc.
• Only .t27 code.

Success Criteria

• The t27c test report on the lab passes for frame_shard.t27 with 0 vacuous tests.
• The spec is sealed at .trinity/seals/t27f_frame_shard.json.