feat: dynamic assume-role support for the AWS S3 service (+ IAM fixes & cleanup)

[davidf-null]

Summary

Adds dynamic assume-role support to the AWS S3 dependency service so the agent
can run AWS operations under a per-service / cross-account IAM role instead of only
its base IRSA identity, plus the IAM-permission and link-workflow fixes found while
testing it, and a final security/docs hardening pass.

Changes

Dynamic assume role

• New assume_role_arn in values.yaml. When set, the agent calls sts:AssumeRole
  with its IRSA identity and uses the temporary credentials for all subsequent AWS
  calls (CLI + Terraform). Empty → IRSA is used directly.
• Hard-fail (no silent fallback) if the assume-role call fails.
• Credential isolation: link actions (build_permissions_context) unset any
  inherited AWS_* credentials before sourcing assume_role, so the call always
  starts from the IRSA identity and never tries to re-assume an already-assumed role
  (self-assume failure).

Requirements module — optional role creation

• create_role (bool) to optionally create the IAM role inside the module.
• trusted_arns (list) for the principals allowed to sts:AssumeRole.
• Exposes role_arn / role_name outputs. Backwards compatible: existing
  role_name behavior unchanged.

module "s3_requirements" {
  source       = "./requirements"
  name         = "prod-us-east-1"
  create_role  = true
  trusted_arns = ["arn:aws:iam::123456789012:role/my-other-role"]
}

IAM permission fixes (required by the AWS provider)

The provider refreshes the full bucket configuration on every plan, so the
bucket-management policy now grants the complete s3:Get* read set:

• Added missing bucket read permissions.
• Corrected action names: s3:GetReplicationConfiguration,
  s3:GetEncryptionConfiguration / s3:PutEncryptionConfiguration.

Link / state fixes

• build_context: always export the link context vars and surface errors to stderr
  for visibility in NP logs.
• tofu init -reconfigure to handle stale backend state in OUTPUT_DIR.

Security & docs hardening

• Removed the hardcoded testing ARN from values.yaml; assume_role_arn now
  defaults to "" so the published service stays account-agnostic. The
  account-specific ARN is provided per installation via --overrides-path.
• Deleted local np-api-skill.{key,key.admin,token} credential files and added
  np-api-skill.*, *.key, *.token, *.pem, .claude/ to .gitignore so
  credentials can never be committed.
• README: documented credential isolation before assume role, expanded the agent
  IAM permissions section (three policies + why the full read set is needed), and
  clarified the account-agnostic override note.

Note: the real account ID 235494813897 was introduced for testing in
445c5c8 and remains in the branch history; it is removed from the working tree
but not scrubbed from history (account IDs are low-sensitivity).

Test plan

• create_role = false + role_name set → existing behavior unchanged
• create_role = true + trusted_arns populated → role created with correct
  trust policy and all 3 policies attached; role_arn output correct
• assume_role_arn empty → IRSA used directly end-to-end
• assume_role_arn set (cross-account) → create/update/link/unlink all run
  under the assumed role; link actions do not hit a self-assume failure
• Bad assume_role_arn → workflow aborts immediately (no IRSA fallback)
• Plan/apply succeeds with the expanded s3:Get* read permissions

🤖 Generated with Claude Code