Add setTargets script for bulk assessment targets - #11

the mock in the earlier review faked responses. testing against the real dev api (apid.ostrichcybersecurity.com) with a real Manager-scoped key surfaced two real bugs the mock's wrong assumptions had hidden, both fixed and reverified against the real api:

• save_targets() crashed with KeyError: 'response' on every real, successful save. the targets endpoint only ever returns {"message": ...}, no response envelope, unlike every read endpoint. confirmed live: the write always landed correctly server-side, only the client crashed reading its own success. fixed by making the envelope check opt-out per call instead of universal.
• an unattended run that hit the shared-targets prompt with no answerable stdin caught EOFError and returned False, so it printed "treating as no" and exited 0 having saved nothing, indistinguishable from a deliberate skip. now raises and exits non-zero. found this because sys.stdin.isatty() reports True under < /dev/null redirection on this platform (windows git bash + native python), so the early refusal never fired and the run reached the actual prompt. --dryRun no longer reaches the prompt at all now either, since a dry run should never block on an answer it doesn't need.

one open, known limitation from the same pass: if one assessment already saved before a later one in the same run hits this exact eof case, the run exits without printing the usual saved-count summary. the values already saved are correct and unaffected, only the summary line is missing. not fixed here, flagged for a follow-up.

GET /v1/businessUnits/ (the first call --template makes) 500'd against the real dev api for a key scoped to a business unit that isn't top-level in firestore, reproduced with a raw curl outside the script entirely. every other endpoint (assessments, content, scores, the targets put itself) resolved the same nested bu correctly via its path parameter. a key scoped to a subsidiary or department rather than the company root is a completely normal way to scope a customer key, so this blocks --template for exactly that case.

this is a backend defect, not something in this PR's diff, and out of scope to fix here. worth its own ticket against emu.

the readme states the requirement as the Manager role on the business unit and does not go below that. that is what the deployed api checks and what its 403 names, and it stays accurate as role handling changes, so the readme should not need rewriting later.

the closed-assessment row quotes Cannot save scores or targets on a closed assessment for the same reason. that is the message the shared scores-and-targets handler returns, ahead of the targets-only mapping further down.

/scores returns one entry per function, category, question and aspect. the nodes map in /content holds every function, category and question, so removing those keys and the summary row leaves the aspects, which are the only ids that accept a target.

matching a pattern against the ids would also work for the built-in frameworks, where an aspect id like GV.OC-1-PROCESS has one more hyphen segment than the question GV.OC-1. custom content types don't have to follow that shape, so the script derives the set instead.

targets are attributed to the account that created the key, not to the key itself. on an aggregate business unit that means a bulk load replaces that user's own targets and leaves every other manager's in the average, so the same csv gives a different result depending on who runs it. the script reads the existing contributors out of targetLabels and the per-sub target values, names them, and asks before writing.

the read-back check afterwards confirms a requested value is present on the assessment, not that it is attributed to the caller. the public api doesn't expose the calling account's own subId, so per-user verification isn't available; requiring target and weight to match one contributor closes the worst version of it, where one manager's target paired with another's weight read as a match. the readme says this in as many words rather than claiming more than it checks.

switching the strategy afterwards is not neutral either. aggregate to override carries the averaged values over, but only on assessments that have never held override targets before, otherwise the older override values resurface. override to aggregate carries nothing over.

• ostrichApi/ is vendored per folder, matching exportAssessmentStatus/ and createScenarioFamilies/. no shared package.
• template files are written utf-8 with a BOM so excel round-trips them as utf-8; reads use utf-8-sig either way, and a non-utf-8 file gets a save-as instruction rather than a stack trace.
• decimal targets like 75.0 are rejected rather than coerced. guessing at a malformed value is worse than naming the row.
• rows with both target and weight blank are skipped, so a partly filled template is a valid input.
• every request has a 180s timeout and --baseUrl has to be https, since the key and the token both cross it.
• requests is pinned at 2.34.2.
• root README.md now indexes the three script folders, since customers land there from a shared link.
• adversarially reviewed cross-vendor before this went up. the fail-closed batching, the prompt handling and the read-back semantics above all came out of that pass.