Teach the OIDC subject format that GitHub now sends

[MaxThePrisberry]

Every fork created this semester will fail to assume the AWS role, because GitHub changed the OIDC subject claim and the course still teaches the old one. I reproduced it end to end in my own AWS account and confirmed the fix.

The test ran one workflow on one branch - only the trust policy changed between the two runs.

Phase 1, the policy the course produces today, names only:

ASSUME OUTCOME = failure
Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

Phase 2, same workflow, same branch, subject switched to the format in this PR:

ASSUME OUTCOME = success

GitHub applies this to every repository created after July 15, 2026, and to any account or repository renamed after that date. That makes it the whole class this semester rather than an edge case:

https://github.blog/changelog/2026-04-23-immutable-subject-claims-for-github-actions-oidc-tokens/

Any student can read their own subject with this, which is also how they get the two IDs:

gh api repos/YOURGITHUBACCOUNT/jwt-pizza/actions/oidc/customization/sub

What changed:

• awsS3Deployment.md sets the subject right after the role is created, so students never meet the error.
• gitHubEnvironments.md and awsEcr.md use the same format. The ECR step extends the condition now instead of replacing it, which used to undo the IDs set earlier.
• faq.md keeps the recovery section from Updated S3 Deployment to include modified GitHub usernames. #229 where you put it, and widens it to cover roles created before this change. It reads both IDs from one API page, and fixes two typos in the example subject, re:refs/heads and refs/head/main, that fail on a copy and paste.

Two details worth a look:

• The subject sits under StringLike rather than StringEquals, because StringEquals treats the trailing wildcard as a literal character and silently never matches.
• That wildcard covers any branch or environment, so the environment:production entry is no longer needed and deliverable 7 no longer has to rewrite the array.

If you'd rather pin each case exactly instead of using a wildcard, say so and I'll rewrite it that way.

[leesjensen]

Great contribution. Thanks for working ahead and providing such a complete solution.

I'm wondering if we even need the FAQ update. We can probably just remove it as it was not addressing the real issue and moving forward won't be needed.