[feat]: Display service-to-service base URL in each service's Interfaces tab

[7thgenerationdesign]

Prerequisites

• I have searched for existing issues that already suggest this feature.

Describe the Feature Request

For services that expose machine-readable interfaces (APIs intended to be consumed by other StartOS services rather than human browsers), display the canonical internal URL — http://<package-id>.startos:<internal-port> plus any required path prefix like /v1 — alongside the existing LAN/HTTPS interfaces in the Interfaces tab.

Describe the Use Case

StartOS 0.4.x supports inter-service communication via <package-id>.startos DNS names on a shared internal network, but this URL pattern is not surfaced anywhere in the web UI. Today, users discovering it have to:

1. Read another package's hard-coded configuration (e.g., Open WebUI's default http://searxng.startos:80/search?q=... for the SearXNG integration) and reverse-engineer the convention.
2. Cross-reference the consumer package's README against the producer package's README to figure out which internal port to use, since the Interfaces tab only shows the LAN-mapped port.
3. Know that OpenAI-compatible services require a /v1 suffix that isn't part of the StartOS interface metadata.

The result is that "two StartOS services should talk to each other" — a workflow the platform's design encourages — is harder to accomplish than connecting a third-party app to a single StartOS service.

Describe Preferred Solution

Extend the package manifest schema (or the existing interface metadata) to allow each interface to declare:

• An internal_url field (e.g., http://maple-proxy.startos:8080)
• An optional base_path field (e.g., /v1)
• An optional auth_hint field (e.g., "Bearer token in Authorization header" or "None required")

Display these in the Interfaces tab in a dedicated "Service-to-Service" or "Internal API" section, distinct from the user-facing LAN/Tor/hostname.local URLs. Include a copy-to-clipboard button.

Describe Alternatives

• Add a section to each individual service's README documenting its internal URL (workable but doesn't scale; see Issue 4).
• Document the convention once in core StartOS docs and rely on users to apply it (current de-facto situation; not discoverable enough).
• Expose internal URLs only via start-cli (CLI-only is fine for power users but doesn't help GUI users).

Anything else?

This change would potentially make the Open WebUI auto-detection feature request I just submitted dramatically simpler to implement — Open WebUI could just read the manifest of each installed AI service and pull the correct URL directly, rather than maintaining a hard-coded allowlist.

[dr-bonez]

why not use the bridge interface url as-is?

[7thgenerationdesign]

I imagine using the internal URL would eliminate the chance of any future issues arising from LAN IP or hostname being modified, and then connections being broken.

[7thgenerationdesign]

Concrete repro of the "unrecoverable on restart" behavior referenced here: a package's startup config-watcher throwing (Start9Labs/open-webui-startos#23) leaves the service hung indefinitely on "Starting…"/"Restarting…" with no recovery path in the StartOS UI — the only way out was uninstalling and manually relocating the data volume on the filesystem. Suggest StartOS surface a failed startup procedure as a clear "Failed to start" state with a recovery/rollback affordance, rather than an open-ended spinner.