Fix PoE1 3.29 updater and macOS display scaling

[ocombe]

Summary

• bump the bundled PoE1 submodule/version from v2.63.0 to v2.66.2 so new packaged apps include runtime/lua/sha2.lua
• allow upstream runtime/lua/*.lua files through the macOS update manifest as a normal updater-managed pseudo part under App Support src/lua
• prepend App Support src/lua to LUA_PATH while keeping bundled Resources/lua as the fallback
• run the macOS bundle without the Retina/DPI_AWARE renderer path to avoid the external-display startup bug where PoB renders into the lower-left quadrant until the window is dragged across monitors
• update the macOS port docs for both runtime Lua updates and the DPI workaround

Fixes #2.

Validation

• luajit syntax check for macos/mac_entry.lua
• Lua harness verifies the manifest filter rewrites lua/sha2.lua to runtime_lua and drops non-Lua runtime files / Windows binaries
• git diff --check
• cmake -B build -DCMAKE_BUILD_TYPE=Release
• cmake --build build
• cmake --install build --prefix , verified Resources/lua/sha2.lua and CFBundleShortVersionString=2.66.2
• macos/sign.sh /Path\ of\ Building.app
• codesign --verify --deep --strict --verbose=2 /Path\ of\ Building.app
• installed locally to /Applications/Path of Building.app, verified codesign, CFBundleShortVersionString=2.66.2, NSHighResolutionCapable=false
• fresh launch from saved external-monitor position renders full-window instead of lower-left quadrant

[rchasman]

I hit this from the user side (needed 2.66.2 on macOS, mac-v0.1.2 cannot get there) and went looking for exactly why the update cannot deliver sha2.lua. Writing up the trace in case it is useful for reviewing this PR. All line references are upstream v2.66.2.

The update path filters the file out by platform, three steps in:

1. manifest.xml:5 declares the runtime source as Windows-only:
   <Source part="runtime" platform="win32" url=".../runtime/" />
2. UpdateCheck.lua:158 only accepts a node when not node.attrib.platform or node.attrib.platform == localPlatform, so on macOS every part="runtime" entry is skipped.
3. manifest.xml:398 classifies the file in question as runtime:
   <File name="lua/sha2.lua" part="runtime" sha1="be12047..." />

So an in-app update on macOS advances src/ to 2.66.x while runtime/lua/ stays at whatever the bundle shipped. In mac-v0.1.2 that means no sha2.lua at all, which I confirmed against the released DMG.

That matters in 2.66.2 because Classes/PoEAPI.lua:2 now starts with local sha = require("sha2").

One detail worth knowing for reproducing it: the breakage is not at launch. getClass in Modules/Common.lua:68 only calls LoadModule("Classes/"..className) on first use, and PoEAPI is instantiated from ImportTab.lua:477 and TradeQuery.lua:62. So a macOS install that updated itself to 2.66.x starts normally and looks healthy, then fails the first time the user opens PoE account import or runs a trade query. Anyone testing by launching the app and seeing it come up fine would conclude the update worked.

sha2.lua is new in 2.66.2 (git log on the file shows b23da8f Release 2.66.2), and the only consumer is PoEAPI.lua, so 2.63.0 was unaffected and this first bites on exactly the upgrade this PR targets.

Which lines up with what this branch does: routing upstream runtime/lua/*.lua through the macOS update manifest as a pseudo-part under Application Support is what closes that gap, rather than the version bump alone.

On the artifact from this branch (run 30198003912), I can confirm the bundle reports 2.66.2, ships Contents/Resources/lua/sha2.lua, passes codesign --verify --deep --strict, and launches on macOS 15.5 arm64. I have not exercised the update mechanism itself end to end, since I installed 2.66.2 directly rather than upgrading a 2.63.0 install, and I cannot speak to the external-display change.