perf: Optimize login latency and reduce redundant I/O in solidui/pod/auth

Description

A performance audit of the login flow has identified several bottlenecks across solidui, solidpod, and solid_auth. The current implementation suffers from redundant network calls, expensive serial I/O, and unnecessary UI blocking.

Identified Issues

1. Redundant Network Requests (P1)
   Duplicate Profile Fetches: getIssuer() and solidAuthenticate() both fetch the WebID profile independently; the second call should reuse the first.

Redundant Session Refresh: solidAuthenticate() triggers a GET request for the profile card even when a valid session is cached.

No Issuer Caching: getIssuer() re-parses the RDF and fetches the profile on every call.

2. Excessive Local I/O & Deserialization (P2)
   Repeated State Checks: isUserLoggedIn() is called multiple times, triggering redundant secure storage reads.

JSON/JWT Overhead: TokenResponse.fromJson() and JwtDecoder are executed for every resource access (e.g., 13 parallel requests trigger 13 identical decodes).

3. Serial I/O Bottlenecks (P3)
   Synchronous initialization: initPod() handles directory resolution, key file parsing, and file creation (PUT/POST) using serial await loops. These should be executed in parallel where no data dependency exists.

4. UI Blocking (P4)
   Eager Initialization: SolidLogin blocks the initial frame until all folder/file generation and package info parsing are complete.

Inefficient Rebuilds: _initPackageInfo() triggers multiple setState() calls, causing unnecessary UI reconstructions.

Start by tracing getIssuer(), solidAuthenticate(), isUserLoggedIn(), TokenResponse.fromJson(), JwtDecoder, initPod(), SolidLogin, and _initPackageInfo(). Map their network, storage, decoding, initialization, and setState work before changing anything. Done means redundant work is reused, independent initialization is parallelized, the initial frame is not blocked, and unnecessary rebuilds are removed.