Fix telepresence local dev flow and dependency resolution

[phenix3443]

Summary

• make telepresence.sh resolve the real k3s ppanel-server dependency config from ppanel-secret instead of assuming hardcoded local MySQL and Redis endpoints
• port-forward the k3s MySQL and Redis services for the local replacement runtime, validate connectivity before startup, and keep up frontend routed to the k3s backend through same-domain /api requests
• print clearer startup information, including the active admin account, while separating frontend-vs-server dependency output to match the real dependency graph
• automatically lower Telepresence traffic-agent resource defaults so intercepts can fit within the ppanel-dev quota, and document the new behavior in both READMEs

Root Cause

The previous script mixed together frontend and backend dependency assumptions, hardcoded MySQL and Redis targets, and inherited frontend API settings that could point at 127.0.0.1:8080 even in up frontend mode. In the tested cluster, default Telepresence traffic-agent CPU limits also exceeded the remaining quota, which blocked intercept creation.

Validation

• ran bash -n telepresence.sh
• ran ./telepresence.sh up both --frontend admin
• verified the script resolved MySQL and Redis from the k3s ppanel-secret and port-forwarded them locally before starting the local server
• verified the script printed the active admin account from cluster config and kept up frontend semantics aligned with same-domain /api routing to the k3s backend
• verified telepresence helm upgrade applied reduced traffic-agent resources and that both ppanel-server and ppanel-admin-web reached ACTIVE intercept state afterward

Impact

• up frontend now behaves like a true frontend-only replacement
• up server and up both now reuse the actual k3s dependencies by default instead of requiring separately prepared local database endpoints
• Telepresence-based local development is more reliable in the constrained ppanel-dev environment