Plugin crashes in embedded REPL

[superev12]

Description

The Litegitpuller plugin fails to load when the environment is an embedded Jupyter Lite REPL. It looks like this is happening because the REPL doesn't include the file browser.

It would be great to be able to use the plugin within an embedded REPL as well as a whole.

Just scanning the documentation, this might be possible if we used ContentsManager to access files, rather than IDefaultFileBrowser.

Reproduce

If Jupyter Lite is hosted on localhost:8000, go to http://localhost:8000/repl/index.html?repo=https%3A%2F%2Fgithub.com%2Fbrichet%2Ftesting-repo&urlpath=notebooks%2Fsimple.ipynb&branch=main

Expected behavior

The git repo is fetched and the notebook loaded the same as it is on http://localhost:8000/index.html

Browser Output

Plugin '@jupyterlite/litegitpuller:plugin' failed to activate. TypeError: No provider for: @jupyterlab/filebrowser:IDefaultFileBrowser.
    resolveRequiredService index.js:574
    n index.js:453
    activatePlugin index.js:453
    e index.js:494
    activatePlugins index.js:492
    start index.es6.js:248
    T index.js:517
    69610 bootstrap.js:177
    69610 bootstrap.js:148
    Webpack 5
[index.js:497:36](webpack://_JUPYTERLAB.CORE_OUTPUT/node_modules/@lumino/coreutils/dist/index.js)
    e http://localhost:8000/build/jlab_core.b189e4f.js:1
    activatePlugins http://localhost:8000/build/jlab_core.b189e4f.js:1
    start http://localhost:8000/build/jlab_core.b189e4f.js:1
    T http://localhost:8000/build/6584.3a10d08.js:1
    69610 http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
    69610 http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
    w http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
    k http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
    O http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
     http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1
     http://localhost:8000/build/repl/bundle.js?_=c3ceefd:1

[brichet]

Thanks @superev12 for looking into this.

👍 Using the contents manager instead of the IDefaultFileBrowser may fix this issue, indeed.

Do you think that you can test it and open a PR with the relevant changes ?