fix: service detection in vip dev-env logs

[sjinks]

Description

This PR fixes service detection for the vip dev-env logs command.

The previous implementation:

• did that incorrectly because it assumed the wrong data type;
• unnecessarily run the full environment health check to get the list of available services.

This implementation fixes that and is more stable for faulty dev environments.

Changelog Description

Fixed

• vip dev-env logs implementation. It is now faster and more stable.

Pull request checklist

• Update SETUP.md with any new environmental variables.
• Update the documentation.
• Manually test the relevant changes.
• Follow the pull request checklist
• Add/update automated tests as needed.

New release checklist

• Automated tests pass.
• The Preparing for release checklist is completed.

Steps to Test

vip dev-env logs -S inx before and after this PR.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Fixes how vip dev-env logs validates the --service option by avoiding landoInfo() (and its full health check) and by correcting the Lando AppInfo.services typing that previously led to incorrect substring matching.

Changes:

• Update Lando core typings so AppInfo.services is typed as a string (matching runtime output).
• Export getLandoApplication() for reuse outside dev-environment-lando.ts.
• Change showLogs() service validation to use the Lando App service list derived from the initialized application (instead of landoInfo()), and tweak debug formatting.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 3 comments.

File	Description
types/lando/plugins/lando-core/lib/utils.d.ts	Corrects AppInfo typing to match actual startTable() output and allows extra keys via Record<string, unknown>.
src/lib/dev-environment/dev-environment-lando.ts	Exposes getLandoApplication() so other modules can reuse the cached/initialized Lando app without triggering health checks.
src/lib/dev-environment/dev-environment-core.ts	Updates vip dev-env logs service validation to use the initialized Lando app’s service metadata and improves the error message.

[Copilot]

Service names are being derived from application.info here. App also exposes application.services (string[]) which is the canonical service list and is already filtered in initLandoApplication (e.g., initOnly services removed). Using application.services avoids relying on info shape/completeness and keeps the validation consistent with the service list Lando itself tracks.

Suggested change

	const services = application.info.map( service => service.service );
	const services = application.services;

[sjinks]

No, this is wrong. application.services differs from application.info. The former lists only active services (e.g., excluding init-only containers), while the latter includes information about all services.

For example,

• Services from application.info: ['nginx', 'php', 'database', 'memcached', 'wordpress', 'vip-mu-plugins', 'demo-app-code']
• Services from application.services: ['nginx', 'php', 'database', 'memcached']

Init-only containers also produce logs, and if we use application.services, we won't be able to watch their logs without the low-level docker logs command