M4 §4/6: the migration permission fix leaves Migration files owned by http:http and read-only

From beta feedback by @yard-mschwartz (2026-08-10 batch).

The permission fix helps to create the Migrations dir and the migration file, but it ends up in read-only mode. The directory and the file are created as http:http, not as mschwartz:mschwartz. I also put 757 on the directory and 646 on the file, so it matches the permissions of the other files we're working with, but maybe this was not needed.

PHP Track > M4 Database Layer > Section 4/6, Common Problems.

This is a partial fix, not a missing one — the Common Problems entry already documents a permission workaround, and it does get the Migrations directory and migration file created. The gap is what happens next: occ runs as the web-server user inside the container, so the generated files come out owned by http:http and the reader, working from the host, can't edit the very file the next step tells them to edit.

To sort out when picking this up:

• Extend the Common Problems entry so it covers ownership, not just creation.
• Give one recommended way to fix it rather than leaving readers to guess — chown back to the host user is the obvious candidate.
• Answer Marc's open question: were his 757/646 needed? Almost certainly not, and we should not leave a beta tester with the impression that world-writable-ish modes are the expected course of action. Recommend concrete, sane modes.
• Check whether the same thing bites anywhere else occ generates files the reader then edits.

Locate the PHP Track > M4 Database Layer > Section 4/6 Common Problems entry and read its existing permission workaround. Check how container occ creates the Migrations directory and file, including ownership and modes, and whether the same issue appears elsewhere. Update the entry with one host-ownership remedy and concrete sane permissions, explaining why 757/646 are unnecessary.