Validate an exported OneRoster 1.2 CSV bundle against its manifest.csv before treating it as complete

Steps

1. Parse manifest.csv as a simple long-format table with exactly two columns, propertyName and value — one property/value pair per row, per the 1EdTech OneRoster CSV Binding spec, not a wide table with one column per file.
2. Confirm manifest.version and oneroster.version rows are present and that oneroster.version matches the version (1.2) the bundle claims to implement.
3. For every file.<table> property (e.g. file.orgs, file.users, file.classes, file.enrollments, file.academicSessions, file.courses), verify the declared value is bulk, delta, or absent, and cross-check against the zip contents: a file marked bulk or delta must actually be present, and one marked absent must not be.
4. Read the source.systemName / source.systemCode rows where present to confirm the exporting system identity matches what's expected for this feed before ingesting.
5. Treat the manifest as the authoritative file inventory: reject the bundle if any CSV file physically present isn't declared in the manifest, or any file declared bulk/delta is missing from the zip, before running per-row validation on the individual data files.