Verify each finding against the current code and only fix it if needed.

In `@internal/auditlog/middleware.go` around lines 214 - 221, The code fails
because plan.Policy.Features.Fallback is a *bool but ExecutionFeaturesSnapshot
(and/or FeatureFlags) expects a bool; change the snapshot to preserve the
pointer semantic by making ExecutionFeaturesSnapshot.Fallback a *bool (or the
corresponding FeatureFlags.Fallback field a *bool) and assign it directly
(Fallback: plan.Policy.Features.Fallback) so nil remains "default on" rather
than collapsing to false; update any JSON/tags and callers to handle a *bool
where necessary.

#!/bin/bash
# Check the Fallback field type in core.ExecutionFeatures
rg -n "Fallback" --type go -C 3

echo "---"
# Check what type plan.Policy is in core.ExecutionPlan
rg -n "Policy" internal/core/execution_plan.go -C 3

echo "---"
# Check compiler.go around line 29
cat -n internal/executionplans/compiler.go | head -60

echo "---"
# Check core execution_plan.go around line 94
cat -n internal/core/execution_plan.go | sed -n '80,110p'

Learnt from: SantiagoDePolonia
Repo: ENTERPILOT/GoModel PR: 204
File: internal/auditlog/middleware.go:214-221
Timestamp: 2026-04-03T15:08:41.995Z
Learning: In the GoModel codebase (ENTERPILOT/GoModel), `executionplans.FeatureFlags.Fallback` is stored as `*bool` (persisted form, `internal/executionplans/types.go`), but it is canonicalized into a plain `bool` by `FeatureFlags.runtimeFeatures()` (which defaults nil to true) and then stored in `core.ExecutionFeatures.Fallback bool`. By the time `plan.Policy.Features.Fallback` is accessed in `internal/auditlog/middleware.go`, it is already a plain `bool` — do not flag it as a `*bool` type mismatch.

Learnt from: SantiagoDePolonia
Repo: ENTERPILOT/GOModel PR: 33
File: internal/auditlog/auditlog_test.go:272-279
Timestamp: 2026-01-15T23:07:26.646Z
Learning: Go code guideline: Avoid using interface{} and map[string]interface{} for API request/response payload types. This should be restricted to public API surfaces and data payloads. It is acceptable to use interface{} in internal infrastructure packages (e.g., storage abstractions) only to break import cycles, and only when type assertions occur at initialization (not on every request) to minimize runtime type checks and improve readability. Apply this rule broadly to files under internal/ that deal with payload-like types, but not to internal components that are pure infrastructure or have runtime-per-request type assertions.

Learnt from: SantiagoDePolonia
Repo: ENTERPILOT/GOModel PR: 33
File: internal/auditlog/factory.go:112-143
Timestamp: 2026-01-15T23:07:37.652Z
Learning: Guideline: Do not use interface{} or map[string]interface{} for API request/response payload types. Prefer strongly-typed structs for API payload definitions to improve type safety, serialization, and documentation. Allow interface{} only in internal infrastructure code paths where pragmatic flexibility is necessary (e.g., to avoid import cycles or to handle highly dynamic internal contracts). In internal/auditlog/factory.go and similar non-API implementation files, applying this restriction is optional and should be evaluated on a case-by-case basis based on whether the type remains internal and does not define API boundary shapes.

Verify each finding against the current code and only fix it if needed.

In `@internal/admin/dashboard/static/js/modules/execution-plans.test.js` around
lines 267 - 284, Add a third assertion to the existing test for
executionPlanChartWorkflowID: when the source object has a normal non-sentinel
id (e.g., { id: 'workflow-123' }), the function should return that id directly
regardless of the entry’s execution_plan_version_id; update the test in
execution-plans.test.js (within the test that uses createExecutionPlansModule()
and calls module.executionPlanChartWorkflowID) to include an assertion that a
non-sentinel source id is returned unchanged.