Remove the circular dependency between the HAPI service and its database

[KyleOps]

Problem

cdk deploy fails on both stacks during change set creation, so #2065 cannot actually be deployed:

Circular dependency between resources:
[EhrProxyHapiEhrProxyHapiServiceSecurityGroupfrom...LoadBalancer...,
 EhrProxyLoadBalancerSecurityGroupto...HapiServiceSecurityGroup...,
 EhrProxyHapiEhrProxyHapiService...,
 EhrProxyHapiEhrProxyHapiServiceSecurityGroup...,
 EhrProxyHapiEhrProxyHapiDatabaseSecurityGroupfrom...IndirectPort...]

The cause is a single line introduced in #2065:

this.service.node.addDependency(this.database);

It reads like a harmless ordering hint. The catch is that node.addDependency applies across whole construct subtrees, not between the two resources named. So it made the HAPI service's security group depend on the database's ingress rule, and that ingress rule already references the service's security group. That closes the loop, and CloudFormation rejects it.

Fix

Remove the line. The ordering it was meant to guarantee already exists implicitly:

• SPRING_DATASOURCE_URL resolves the database endpoint through Fn::GetAtt, and the credentials resolve through the generated secret, so the task definition cannot be created before the database.
• The service references its task definition, so the service cannot be created before the task definition.

Verified in the synthesized template: the task definition does reference the database via Fn::GetAtt, and the service SG's DependsOn is back to just its task role.

A comment now records why the line must not come back, since re-adding it looks like an obvious improvement.

Verification

The earlier cdk diff runs on #2065 had silently fallen back to a template-only comparison, printing "Could not create a change set, will base the diff on template differences". That message was CloudFormation rejecting the cycle, and it is why this was not caught before the deploy attempt. Template-only diffs do not validate the resource graph.

With this change, cdk diff creates a real change set against both deployed stacks, which is CloudFormation validating the graph:

Stack	Change set	Additions	Deletions
EhrProxyAppStack	created cleanly	6	none
FormsServerAppStack	created cleanly	6	none

The intended change is otherwise unaffected: the same RDS instance, subnet group, security group, ingress rule, secret and secret attachment, plus the expected ECS task definition revision.

Blast radius of the failed deploy

None. The deployment failed at change set creation, before any resource was touched:

EhrProxyAppStack  UPDATE_COMPLETE  2025-08-27T02:26:16Z   (unchanged)
RDS instances     none for either stack
proxy.smartforms.io/fhir/metadata -> 200