fix(resource): expose application resource map

[benletchford]

Closes #579

Cause

Systemless indexed application resources only in host-side Resource Manager state. Classic runtimes that walk TopMapHndl directly therefore saw a NIL map, failed to install their relocation hooks, and later treated segment-relative code targets as low-memory addresses. Native resource-map code also could not read the already-open application resource fork through its FCB because the serialized fork was not mounted on that path.

Fix

• retain the serialized resource map and complete fork when parsing resources
• publish an application resource-map handle through TopMapHndl
• populate each resource reference record with its live guest handle
• expose the serialized application resource fork to native PBRead calls

Evidence

The authentic issue reproducer now completes relocation, initializes QuickDraw, opens its scenario data, and reaches ExitToShell with a valid tick count instead of recursively re-entering startup and wrapping TickCount to $FFFFFFFF.

Tests

• cargo test --lib load_resources_exposes_application_map_and_fork_to_native_runtime_code --no-default-features
• cargo test --lib --no-default-features (2,941 passed, 3 ignored)
• authentic issue Classic segmented 68k applications can recurse through startup and corrupt TickCount #579 application startup probe