If needed, the install folder is always available from the .ZIP download. You can extract just the install folder, without any intention to actually install or use it. You're just trying to get the PHP Info from a place that doesn't require logging into phpBB ACP.
php-development.ini is a copy of what the suggested developer configuration settings are (loud errors, etc.). The file you want to look at is simply php.ini. But yes, the line you saw,
;extension=sodium
, represents the sodium module being
disabled. So if you look in the php.ini and see that same line, remove the semi-colon from in front of it, so that it's just
extension=sodium
and save the PHP.INI file.
Even just having a unique phpBB database table prefix name within a single database should be enough to keep your sites separate. Having separate database names is even better, so long as your host says there isn't any database limit this would exceed. With separate database names, you can even keep the default phpbb_ table prefix in both, and they are still completely separate. If you were making a second production site, perhaps you would also need to talk to the host about database connection limits. But for a test site only you're using, I'm not expecting there to be an issue.
The only "obvious" problems to me is when you want to use a backup copy of the production database to restore to the test site. Which is absolutely the way I would use it, because testing with your 400K or however many messages can be a better test than "just a few forums and test posts" when testing updates or trying new extensions, etc. Plus I've used that to trial things like database left-right fix-ups against my message store to make sure I get the correct result, before doing it against the production site. Things that "only an actual copy of the production database" can tell you.
The things to watch for are already called out in in
Knowledge Base - Transferring Your Board to a New Host or Domain. Because that's effectively what you're doing when taking the backup of production.domain.com and restoring it over on test.domain.com.
Specifically the steps of making sure
"Force server URL settings:" isn't enabled, since otherwise logging in on the test board could send you over to the production site. And adjusting the cookie settings, so that the cookies saved and used when logging into test.domain.com don't stomp on your cookies for the production site. (Which only affects you, since you're the only one logging on to the test site, but still.)
For my own sanity I would probably re-color the site style & even the ACP's admin.css background so that it was very clear when I was on the test site versus the production site. But that happens even with a local XAMPP site or anything that's an actual restored backup of your site.