Contain paths taken from a project file

Several places in the CLI take a path out of a project's own files and use it directly, so a project you did not author can point them anywhere on the machine.

openfn project clean deletes whatever dirs.workflows points at. Setting it to ../victim in a checked-in openfn.yaml removes that directory, because Workspace.workflowsPath builds it with a bare path.join and clean.ts rimrafs the result.

A step id goes into a cache filename without being flattened, so an id of ../../../../pwned writes outside the cache root, and load-state.ts reads that same path back as the run's starting state.

A symlink committed into a workflow repo is followed. The containment check in from-fs.ts resolves the directory a file sits in but not the file itself, so a link at the end of the path passes and whatever it points at is read in as a job's source and pushed on the next deploy. Git preserves symlinks, so a cloned repo is enough.

The awkward part is that some of these paths are legitimately absolute and outside the project, and the CLI's own fixtures rely on it, so a blanket refusal breaks real usage. Worth deciding once rather than per site.

Came up while looking at how names become filenames for lightning#4577. None of it needs an unusual name.

Start by tracing Workspace.workflowsPath into clean.ts, then inspect the cache filename handling and load-state.ts. Read from-fs.ts to understand the existing containment check and how symlinks are handled. Done means one agreed path-containment policy covers these cases without breaking the absolute external paths used by the CLI fixtures.