Missing `Gemfile.lock` error includes `ls: cannot access 'la': No such file or directory`

### STR:

1. `mkdir testcase && cd $_`
2. `touch Gemfile`
3. `pack build --buildpack heroku/ruby testcase`

### Expected

* Error message that explains `Gemfile.lock` is missing, and for bonus points includes the directory listing of the source.
* For that error message not to include any additional errors or warnings generated whilst rendering the error message.

### Actual

```
===> BUILDING

## Heroku Ruby Buildpack

- Could not find `/workspace/Gemfile.lock`, details:
- failed to open file `/workspace/Gemfile.lock`: No such file or directory (os error 2)
- Debug info Contents of the `/workspace` directory
- Running debug command `ls la /workspace`

ls: cannot access 'la': No such file or directory
/workspace:
Gemfile
README.md
bin

- Done (< 0.1s)
- Command failed `ls la /workspace`
exit status: 2
stdout:
stderr:

! Error: `Gemfile.lock` not found
!
! A `Gemfile.lock` file is required and was not found in the root of your application.
!
! If you have a `Gemfile.lock` in your application, ensure it is tracked in Git and
! that you’re pushing the correct branch.
!
! For more information:
! https://devcenter.heroku.com/articles/git#deploy-from-a-branch-besides-main
```

Note the `ls: cannot access 'la': No such file or directory`.

Suggested next steps:
1. Fix the args to `ls` (to use `-la` instead of `la`)
2. Add `libcnb-test` integration test coverage of the full output here (such a test would be fast to run, since it's a failure right at the start of the build, plus IMO the error messages around onboarding an app to the CNB are high priority for UX/DX and so worth ensuring all are tested)
3. Ideally reducing some of the unnecessary repetition in the build output. For example there's a lot of duplication around `Could not find` + `No such file or directory (os error 2)` before the actual error message. For some other type of I/O error, there is value in exposing the underlying error, but for this "file not found" case I don't think that pre-amble is needed (the only useful part of it is the absolute path to the Gemfile.lock, which could be inlined in the actual error message etc).

cc @schneems