Fix/remove ordinal position seeding

[Dylan0203]

Summary

Remove ordinal position pre-seeding that causes status bar icons to be placed at the far left of the menu bar instead of near Control Center.

Changes

• Remove seedPositionsIfNeeded() calls from init(), recreateItemsWithBumpedVersion(), and recoverStartupPositions()
• Remove dead code: seedPositionsIfNeeded(), forceMainAndSeparatorAnchorSeed(), shouldForceAnchorNearControlCenterOnLaunch(), shouldSeedPreferredPosition()
• Update corruption recovery tests to expect cleared positions (nil) instead of seeded ordinals (0, 1)

Related Issues

Follows up on the self-healing autosave fix adopted in v2.1.16.

Root Cause

The pre-seeding writes main=0, separator=1 to NSStatusItem Preferred Position keys before creating items, assuming macOS interprets these as ordinal hints (0 = rightmost). In practice, macOS treats them as literal pixel X
coordinates — placing the main icon at X ≈ 0 (far left). When HidingService expands the separator to ~5000px, the misplaced main icon gets pushed off-screen.

The version bump mechanism doesn't help because it re-seeds the same (0, 1) values each time — creating an infinite loop.

Before (all autosave versions):

Main icon: X = -1, separator width = 5002 ← icon pushed off-screen

After (macOS auto-places without seeding):

Main icon: X = 3483, Separator: X = 3461 ← correct, near Control Center

Without pre-seeding, macOS auto-places new NSStatusItems near Control Center correctly.

A Note

Sorry that my previous PR's approach (bumping baseAutosaveVersion to 8) didn't fully solve the problem — it escaped the corrupted cache initially but the re-seeding brought the issue back. I'm not an expert on macOS internals; I just
dug into the UserDefaults/ByHost state and Accessibility API output to trace the actual icon positions, then worked with Claude to get the tests passing and verify the fix on my machine. Hopefully this is closer to the real root cause
this time.

Testing

• Ran ./scripts/SaneMaster.rb verify (build + tests pass)
• Tested manually on macOS
• Added/updated tests for new functionality
• Verified icon position via Accessibility API (X = 3483, right side)
• Confirmed all 62 tests pass across 3 suites
• Verify on clean install (no existing UserDefaults)
• Verify existing healthy user layouts are preserved across update

Screenshots (if UI changes)

N/A — menu bar icon returns to its expected position near Control Center.

Checklist

• Code follows project style guidelines
• Self-reviewed the code
• Commented complex logic
• Updated documentation if needed

Sane Philosophy Check

"Not fear, but power, love, and sound mind" — 2 Timothy 1:7

• Fear: Does this REDUCE user fear, not create it?
• Power: Does the user maintain control?
• Love: Does this genuinely help people?
• Sound Mind: Is the UI clear and calm?
• Grandma Test: Would her life be better with this installed?

[Dylan0203]

Hi Mr. Sane,

Looks like you've already addressed this from a different angle in 53f49d6 with enforceNonRemovableBehavior — preventing cmd-drag removal from persisting visibility overrides. I just tested the latest main and the icon shows up
correctly.

My PR was tackling what I believed to be the root cause (ordinal pre-seeding values being interpreted as pixel coordinates), but since your fix resolves the issue on my end, I'm closing this.

For what it's worth, here's what I found during debugging in case it's useful for future reference:

• All NSStatusItem Preferred Position values across every autosave version (v2 through v99) in both app-domain and ByHost were clean ordinals (0, 1) — there was no actual WindowServer position corruption
• The main icon was consistently placed at X ≈ 0 (far left), and the expanded separator (width ~5002) was pushing it off-screen to X = -1
• Removing the ordinal pre-seeding and letting macOS auto-place items also resolved the issue independently

Happy to help dig into anything else if needed. Thanks again for the thoughtful project.

Dylan