fix(strategy): scope empty-remote guard to configured remotes; document staleness limit

Addresses two trail-review findings on the local-ref guard:

• URL-push defers forever (fix): git hands the pre-push hook the bare URL as the remote arg when a push targets a URL directly (verified: $1 is the URL, not a name). git never records refs/remotes/<url>/*, so remoteHasTrackingRefs was always false → checkpoints deferred permanently for URL-push workflows. Guard now runs only when the arg resolves to a configured remote (isConfiguredRemote via git remote get-url, local/no-network); a bare-URL target publishes instead of stranding metadata. The first-branch hazard the guard exists for always uses a named remote, so no protection is lost. This also matches the reviewer's "…or default to origin" note.

• Recreated-empty-remote staleness (documented): a tracking ref left from before a remote was deleted and recreated empty under the same URL reads as "established", so v1 could publish to the now-empty remote. Detecting that needs a network round trip, which this design deliberately avoids; the earlier TTL only bounded a network probe's cache and no longer applies. Rare and recoverable — noted inline as an accepted limitation rather than reintroducing the network hit.

Test adds a bare-URL case asserting the guard publishes (does not defer).