Rename the untaggable bucket to unmanageable and widen it

[ale210]

Renames the untaggable bucket to unmanageable and widens what it holds.

untaggable meant one thing: AWS exposes no way to tag this. That left a class of
resource with nowhere to go — things that read as unmanaged forever, where no apply
could ever fix it, so they sat in the report as permanent false positives. Some of them
are in Terraform state already.

What moved

Newly classified as unmanageable, each detected by signal rather than by ARN so it keeps
working as the account changes:

Resource	How it is detected	Why
Autoscaling groups	all of them	An ASG's tags are a separate schema with propagate_at_launch; the provider does not merge default_tags into it
Rules of a VPC default security group	rule's GroupId is a group named default	aws_default_security_group holds its rules inline, so they are not resources of their own
Instances an ASG launched	aws:autoscaling:groupName tag	Importing one would make Terraform fight the ASG and hold state that goes stale on the next replacement
Their EBS volumes	attached to such an instance	Created from the launch template alongside the instance
/aws/lambda/* log groups	name prefix	Lambda creates them on first invocation, before any aws_cloudwatch_log_group could exist
ELB-owned elastic IPs	ServiceManaged field set	The ELB service allocated and owns them; not an aws_eip at all
AWS-owned EventBridge rules	rule's own ManagedBy field set	ecs.amazonaws.com creates and deletes these for capacity providers
Listener default rules	IsDefault	A listener's default rule is its default_action, not an aws_lb_listener_rule
default.* RDS parameter groups	name prefix	AWS reserves the name and creates one per engine family; they cannot be modified or deleted

The VPC default security group itself is deliberately not included. It is taggable, it
currently carries managed-by=terraform-incubator, and it stays in the ratio. Only its
inline rules move.

Effect on the incubator account

Same sweep, before and after:

                    before     after
unmanaged               48        30
unmanageable            28        46
coverage             83.2%     88.8%   (237 of 267)

All 321 ARNs are present on both sides — none added, none removed — and nothing left a
managed bucket. The numerator is unchanged at 237; the ratio moved only because the
denominator shrank by 18.

That jump is a definition change, not progress. The README now records the rename date
so a comparison against an earlier run knows why the number moved.

Checked for over-matching

The risk with signal-based detection is absorbing real work. Verified on a live run that
each of these stayed put:

• the VPC default security group → still terraform-incubator
• the ALB security group and its three rules → still managed
• bastion-incubator-prod and its rules → still unmanaged, which is correct, it is an
  open action item on Bring the shared AWS platform under Terraform incubator#184
• the NAT gateway's elastic IP → still managed; only the two ServiceManaged ones moved
• a real listener rule → still managed; only the two IsDefault ones moved
• RDSOSMetrics and the two /aws/rds/* log groups → still unmanaged
• incubator-prod-postgres15, the parameter group we actually manage → still managed

Note on IAM

Service-linked roles (/aws-service-role/) were already unmanageable and stay that way.
Service roles (/service-role/) are not included — despite the similar name and an
AWS service principal in their trust policy, they are ordinary customer roles that
Terraform can import, so they remain real work.

Docs

scripts/README.md now describes three distinct reasons a resource lands in the bucket,
and flags that members of the third group may well be under Terraform management already —
which is the misreading the old single-sentence explanation invited.