[Schema migration] Oracle FLOAT incorrectly mapped to PostgreSQL DOUBLE PRECISION

Describe the bug

The Oracle-to-PostgreSQL converter maps plain Oracle FLOAT to PostgreSQL DOUBLE PRECISION.

Oracle FLOAT is a subtype of NUMBER. It is distinct from BINARY_FLOAT. Mapping it to DOUBLE PRECISION changes decimal NUMBER semantics to approximate IEEE 754 binary arithmetic.

To Reproduce

Example from https://techcommunity.microsoft.com/blog/adforpostgresql/oracle-to-postgresql-in-vs-code-assessment-conversion-and-validation/4544728:

function from_mills_to_secs(value integer) return float is
  real_value float := 0;
begin
  real_value := value/1000;
  return real_value;
exception
  when zero_divide then
    real_value := 0;
    return real_value;
end from_mills_to_secs;

was converted to:

CREATE OR REPLACE FUNCTION soe.orderentry$from_mills_to_secs(value integer)
RETURNS double precision
LANGUAGE plpgsql
IMMUTABLE
AS $$
DECLARE
  real_value double precision := 0;
BEGIN
  real_value := value::double precision / 1000.0;
  RETURN real_value;
EXCEPTION
  WHEN division_by_zero THEN
    real_value := 0;
    RETURN real_value;
END;
$$;

Expected behavior

• Treat Oracle FLOAT and FLOAT(p) as NUMBER subtypes.
• Map them to unconstrained PostgreSQL numeric by default.
• Keep BINARY_FLOAT to real and BINARY_DOUBLE to double precision.

Note: numeric(38) is not a safe generic default: in PostgreSQL it means
numeric(38,0) and therefore imposes scale zero. Oracle FLOAT(p) specifies
binary precision and no fixed decimal scale, so unconstrained numeric is the
conservative general mapping.

Evidence

The type mappings in instructions.yaml include:

- NUMBER(p,s) -> NUMERIC(p,s) preserving exact precision
- NUMBER with no precision -> NUMERIC (unconstrained)
- BINARY_FLOAT -> REAL
- BINARY_DOUBLE -> DOUBLE PRECISION

There is no rule for plain Oracle FLOAT or FLOAT(p). The packaged feature
mapping documentation and static verification design also list
BINARY_FLOAT and BINARY_DOUBLE, but not FLOAT.

The extractor preserved the source type as float; it did not classify it as
BINARY_FLOAT or BINARY_DOUBLE. Nevertheless, the conversion.log reports:

Mapped Oracle FLOAT to PostgreSQL DOUBLE PRECISION per required mapping.

No such required mapping is present in the instructions.

Start with .github/postgres-migrations/walkthough-validation/config/instructions.yaml and compare its numeric type rules with the conversion.log entry around line 248. Trace how the extracted float type reaches the mapping and review the packaged feature mapping documentation and static verification design. Done means plain FLOAT and FLOAT(p) map to unconstrained numeric while BINARY_FLOAT and BINARY_DOUBLE retain their documented mappings.