[Feature] Loaded Module / Shared Library Viewer

## Problem Statement

TaskSmack has no way to see which shared libraries/DLLs a process has loaded. TaskSlinger has this ("process module viewing"); `tasksmack.md`'s "Current Engineering Direction" names "module inspection" as a candidate area. This is distinct from the open-files work in #183, which covers file descriptors, not loaded code modules.

## Proposed Solution

A new section in `ProcessDetailsPanel` listing loaded modules: name, path, base address, size, and version where available.

## Alternatives Considered

Fold this into the #183 (lsof) work as a combined "open files & modules" view rather than a separate panel section — worth deciding once #183 is actually scoped, since the two share a "drill into what a process has open/loaded" theme.

## Additional Context

Reference the existing per-section pattern already established in `ProcessDetailsPanel.cpp` (`renderIoStats`, `renderNetworkStats`, etc.) — this should follow the same shape.

## Implementation Notes

- Windows: `EnumProcessModules`/`GetModuleFileNameEx` (psapi).
- Linux: parse `/proc/[pid]/maps` for mapped shared objects — a different file/pattern than the `/proc/[pid]/status` and `/proc/[pid]/io` parsers already in `LinuxProcessProbe.cpp`, so it's new parsing code, not a reuse of an existing parser.
- Should be fetched lazily (only while Process Details is open and this section is expanded) rather than every background-sampler tick, same reasoning as the per-connection network view.

Read the per-section patterns in ProcessDetailsPanel.cpp, including renderIoStats and renderNetworkStats, then inspect LinuxProcessProbe.cpp and its existing /proc parsers. Implementations should provide the listed module fields on Windows and Linux, fetch them only when Process Details is expanded, and show them in a new section.

Written by the indexing model from the issue text.