v0.1.7-rc3

One fix on top of 0.1.7-rc2, for harness 0.1.7-rc.2 boots.

Engine preset authoring gave up on a loader race

The plugin authors one stripped copy of the standard preset per hosted engine at boot. It read that source preset from the roster as soon as the agentPresets service existed, and retried only while the service was absent. But a preset row is itself a plugin injected with agentPresets: standard enters the registry when that row's own callback runs, which may land after this plugin's. A read landing in that gap throws Unknown agent preset: standard, and the boot's authoring was abandoned -- one error in the startup log and no loop-engine-<engine> presets on disk, so every session on a hosted engine would fail to mount its preset.

Harness 0.1.7-rc.2 loses that race where rc.1 won it (its loader re-derives skipped bundles and its web patch gained rows, which moves the callback order), which is why this arrived as an rc.2 regression.

The bounded window now covers the read as well as the service (20 attempts x 100 ms). Failures stay advisory: the error is logged once after the last attempt, and a failed pass stays un-memoized so a later engine switch starts a fresh one.

Verified on a real 0.1.7-rc.2 boot with the managed preset directories removed first: all four presets are re-authored and the startup log carries no authoring failure. Two new tests pin the shape -- a roster whose first read rejects and then answers authors without reporting a failure, and a roster that never answers reports exactly once.

No API or peer-range change, so nothing moves for users on either harness line.