feat(deployments): Browse container files and bring them onto the host

[nfebe]

The UI side of flatrun/agent#139. Files could browse and edit a deployment's own directory but not what the running container holds, which is usually where the configuration a user wants lives. The only way to it was a terminal.

Files now switches between the host and a running service. A path brought out of the container lands back in the host view where the existing editor already works, so there is no second editor.

The opposite direction already existed, mounting a host path into a container, which hides whatever the container had there. That asymmetry is what made the container side hard to reach.

Mounted paths carry a tag naming what reads them and where. Their warnings follow what happens: deleting a mounted path takes it from the running container, because the host copy is what the container reads; unmounting first returns the service to its image's content and leaves the copy on the host, where deleting it is harmless.

Browsing needs the service running and an image that ships a shell, since the engine cannot list a directory.

Depends on flatrun/agent#172 for its endpoints.

[sourceant]

Code Review Summary

This PR introduces a significant feature allowing users to browse files inside running containers and 'materialize' them onto the host for editing. It includes a new ContainerFilesPanel component, updates to FileBrowser to display mount status, and corresponding API integrations.

🚀 Key Improvements

• Ability to edit container-native configuration files by bringing them to the host.
• Visual indicators (mount tags) in the file browser to show which paths are active bind mounts.
• Safety warnings when deleting host files that are currently mounted into containers.

💡 Minor Suggestions

• Extract formatBytes to a shared utility.
• Improve error reporting when unmounting from multiple services simultaneously.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

The Math.log(0) case is mathematically undefined and Math.log(bytes) will return -Infinity if bytes is 0. While the if (!bytes) check at the start handles 0, it won't handle cases where bytes is less than 1 (though rare for file sizes). A more robust approach ensures the index is at least 0.

Suggested change

	const formatBytes = (bytes: number) => {
	const formatBytes = (bytes: number) => {
	if (bytes <= 0) return "0 B";
	const units = ["B", "KB", "MB", "GB"];
	const i = Math.max(0, Math.min(Math.floor(Math.log(bytes) / Math.log(1024)), units.length - 1));
	return `${(bytes / Math.pow(1024, i)).toFixed(i ? 1 : 0)} ${units[i]}`;
	};

[sourceant]

When unmounting a path that is used by multiple services, perform the deletions sequentially with better error handling, or ideally use Promise.allSettled if you want to attempt all even if one fails. Currently, a single failure stops the loop, potentially leaving the UI in an inconsistent state regarding what is actually mounted.

Suggested change

	for (const mount of mounts) {
	const results = await Promise.allSettled(
	mounts.map((mount) =>
	deploymentsApi.removeComposeMount(props.deploymentName, {
	source_path: mount.source,
	target_path: mount.target,
	service_name: mount.service,
	})
	)
	);
	const failed = results.filter((r) => r.status === "rejected");
	if (failed.length > 0) throw new Error(`Failed to remove ${failed.length} mount(s)`);